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ABSTRACT 

The 1990 Naval Sea Systems Command Ship Design, Acquisition and Construction (DAC) Study provides a 
stepping stone for the implementation of improvements towards optimizing ship performance, cutting acquisition 
costs, and reducing design c>xle time. With respect to performance, significant ad\ ances in computing power 
coupled with customer oriented design (QFD, AHP, evolutionarv^ optimization, etc) provide both impro\’ements and 
direct means to measure effectiveness of improvements. As for cost, implementation of w orld class building and 
design techniques (concurrent engineering, group tcchnolog>\ CAD/CAM/CAE, etc) coupled with higher fidcliW 
costing methods (ACEIT, POD AC, etc) provide sa\ings and direct measures of effectiveness. Cycle time 
improvements have also been implemented (IPTs, Open System Architecture, 3-D Product Models, etc). However, 
ship design managers have been unable to identiiv' and quantify’ design process effectiveness with respect to the 
impact of those proposed cycle time improvements. 

In order to understand the impact of cycle time improvements, it is necessary’ to examine the meclianisms 
w hich ha\ e lead to increased cycle time including external influences (such as increasing technological complexity 
and budgetary pressures), internal process delays (information flow delays and approval delays) and feedback 
processes (design iteratioa error propagation and design change.) Modeling of such meclianisms. using the 
methods of System Dynamics, prov ides a means to study^ past programs (in particular, the DDG-51 Destroyer 
program of the 1980's), and to study^ the anticipated savings that can be generated with the introduction of process 
improvements. 

Of particular interest in modeling the naval ship design process w ith System Dynamics is the flow of design 
information. Traditional process analysis methods based on the design spiral represent tlie progression of design 
tasks as a linear process. However, actual design data propagation (a fundamental property’ resulting from the 
phy sical and architectural relationships of total ship sy stems) shows the process to be highly non-linear. These non- 
linearities are captured by’ system dy namics, providing a simulation tool tliat more fully captures the impacts of 
process improvements as they relate to the nav al ship design process. 

Thesis Supervisor: Alan J. Brown 

Title: Senior Lecturer. Department of Ocean Engineenng 
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1 Problem Statement 


In June 1990, under the direction of Naval Sea Systems Command (NAVSEA) Chief Engineer, RADM 
Roger Horne, the United States Navy undertook a program to assess the effectiveness of the naval ship design, 
acquisition and construction (DAC) process. The focus of this project was “to identiiy the critical actions necessary 
to improve the quality' of future ship designs (i.e. meeting customer’s performance requirements), to reduce ship 
costs (from research and development through disposal), and to reduce the cycle time required from establishment of 
requirements to delivery of the lead ship.”^ It was immediately recognized that naval ship acquisition is itself 
unique within the constrained framew ork of the Department of Defense (DOD) and Department of the Navy (DON) 
organization. In particular, Navy ships are bought in small quantities, hav e very' long development cycles, and are 
extremely costly.. .precluding the “fly before you buy” approaches required for purchase of other weapon sv^stems.^ 
Additionally, the technical complexity of warship design has passed the point that any “one” individual can be an 
“expert” in all aspects of the design.^ The resulting process is neither well documented nor well understood. 

Although the purpose for the DAC program was very wide-ranging, the specific reasons prompting the DAC 
effort were clear: increasing naval performance requirements are resulting in increasing ship costs and increasing 
cycle times for delive^\^ The resulting ‘Affordability' Crisis”^ put strong pressure on the DOD to reform the 
acquisition process. Tliis “Crisis” is anaty'zed by examining three key symptoms: increasing design cycle time, 
constraints leading to sub-optimal system performance, and increasing cost trends. 

1.1 “Affordability Crisis” 

1.1.1 Cycle Time 

The time required to conceptualize, design and produce new ship designs has been increasing steadily over 
the years. Consider the trends for naval combatant programs shown in Figure 1. Conceptual Design time (concept 
design and preliminary design) is increasing at a rate of 1.5 months per year. Contract Award time (from program 
start through completion of contract design) is increasing at a rate of 3 months per year. Time to deliver completed 
sliips is increasing at a rate of 5 months per year. These trends are coupled witli exponentially increasing man-day 
efforts required to deliver sliip designs (Figure 1). Tliese trends are disturbing as they represent a barrier to 
providing warfigliters with timely systems necessary to meet threats. The causes of these trends are numerous and 
will be discussed in depth in Chapter 2. 


^ RADM Roger B. Home, “Concept to Commissioning: Ship Design, Acquisition and Construction Process 
Improvement Workshop 11”, Richmond, VA, May 6-7, 1991. 

“ Ryan and Jons, “Improving the Ship Design, Acquisition and Construction Process”, Association of Scientists and 
Engineers, 28* Annual Technical Svmposium, April 11, 1991. 

^ Tibbitts and Keane, “Making Design Everybody’s Job”, Naval Engineers Journal, May 1995, page 286. 

^ Timothy P McCue, “The Dv'namics of Naval Shipbuilding-a Systems Approach”, Department of Ocean 
Engineering Thesis, Massachusetts Institute of Technology', June 1997, pages 23-44. 
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Figure 1 Combatant Cycle Time Trends^ 

Tlie reaction to the DAC study and subsequent sliip programs since the realization of these trends was 
significant reform and ‘'modernization” of llie design process. Tliese reforms include revision of the basic 
Department of Defense (DoD) acquisition process requirements (Acquisition Reform), restructuring of the design 
organization to be inclusive of design agents, sliip constructors and customers (IPPD/IPT and Concurrent 
Engineering), and application of data processing advances (SBD and 3-D Product Models). 

One of the most significant process improv ements has come in the form of acquisition reform. Tliese refonns 
have been reahzcd primarily tlirough tlie introduction of DoDFMST 5000-2R, the basic documentation of acquisition 
requirements. 

Another method of reducing cycle time, reducing cost and improving performance is the reform of design 
organizations. Consider the past approaches to nav al design. ^ In the 1950's, the Navy (namely the BuSliips) was 
responsible for complete design of ships and. in many cases, the construction of those designs at naval shipy ards. 
Tills approach to “in-house” design and construction was appropriate and efficient because nav^al ships were 
relatively simple (designs were consistent with World War II technologies). Naval designs that were constructed by 
private shipyards were the result of a largely “non-adv ersarial” relationsliip between the Navy and industrv'. 

In 1960, the Secretary^ of Defense, Robert McNamara, introduced a new method of ship acquisition: Total 
Package Procurement (TPP). This transition was initiated to reduce costs and introduce system design of ships 
based on “ilities” (reliabilitv\ maintainability', survivability, etc.) Under TPP, the Navy independently perfonned 
concept foniiulation (CF) to validate operational requirements against potential ship designs, but the results were 
vvitliheld from industry. Validated requirements (minus design suggestions) were “tlirowm over the wall” to 
industty, which performed independent contract definition (CD). CD established shipbuilder designs and solutions 

^ Ryan and Jons, “Improving the Ship Design, Acquisition and Construction Process”, Association of Scientists and 
Engineers, 28^ Annual Technical Symposium, 11 April 1991, page 10-11. 

^ Keane and Tibbitts, “A Revolution in Warship Design: Navy-Industry' Integrated Product Teams”, Journal of Ship 
Production , November 1996, page 255-259. 
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that optimized utilization of their construction facilities. Ho\ve\'er, the competitive environment prevented the Navy 
from suggesting specific design desires, despite the fact that the Navy retained responsibility for the majority of 
combat sv stems to be integrated with the design. As a result, programs such as the LHA and DD-963 produced high 
quality ships^ (the result of industrv^ optimization of construction), but resulted in large cost overruns (due to late 
design changes and GFE/GFI/GFM delays) and increasingly adv ersarial government-industrv^ relationships.^ As a 
result, TPP fell into disfavor. 

The programs of the 1970’s saw a return to “in-housc” design efforts b>' the Navy'. However, the decline of 
naval shipyards during the period of TPP resulted in the need to rely entirely on priv ate shipyards for construction. 
The newly formed Naval Sea Systems Command (NAVSEA) was responsible for all phases of design through 
contract award. The only inv olvement of shipbuilders was the performance of producibility’ studies to suggest 
largely generic improvements to the design. At the completion of contract design, the design specifications were 
awarded as a ship design support contract to a sliipyard which allowed lead ship detailed design to begin ev en while 
construction contracts were being negotiated The nature of the design process at this point allowed the Navy to 
retain significant, centralized control of the design througliout the life the acquisition. However, industrv was 
increasingly constrained by their late participation with the design, resulting in higher construction costs. 

The 1980's saw an attempt to bnng shipbuilders into the process sooner. During contract design, shipyards 
were invited to participate in the process as observ ers and to introduce extensive producibility' enhancements to tlie 
design. However, the potential shipbuilders could not achieve consensus on the design approach due to the 
substantial differences in their production methods and facilities. As such, NAVSEA designs adopted a “lowest 
common denominator” approach.^ Simultaneously, system integration issues (such as introduction of the Aegis 
Weapons Systems on CG-47 and DDG-51 class ships) became a dominant cost and requirements driv ers for ship 
optimization and design. The result w as the introduction of collocation of design agents and increased use of 
computer aided design (CAD). However, these efforts fell short of their goals. Centralized design control by 
NAVSEA meant that collocation for a single design project might jeopardize av ailability of design resources for 
other design projects. As for CAD, attempts to use a single product model sv stem meant translation errors and 
incompatibihties among as many as six different CAD s> stems in use by private shipyards. 

The lessons of 40 years of process methods are being applied in the 1990’s in an attempt to reverse the cycle 
time trends. With downsizing of government organizations, NAVSEA is transitioning from centralized design 
control to design oversight. Acquisition reform, centered on the Federal Acquisition Streamlining Act (FASA), the 
Federal Acquisition Reform Act (FARA), and DoD Directive 5000.1 (March 15, 1996)^^, prov ides a foundation 
from which government and industry' can mutually benefit in the design process. Specifically, these reforms are 


^ Keane and Tibbitts, “Naval Sliip Design in the 2 Centurv ”, Society of Nav al Architects and Marine Engineers, 
September 14-19 1993, page 19-3. 

^ Kenneth Cooper, Naval Ship Production: A Claim Settled and a Framework Built, Pugh-Roberts Associates. 
Cambridge, MA, December 6, 1980. 

^ Keane and Tibbitts, “A Revolution in Warship Design: Navy-lndustrv' Integrated Product Teams”, Journal of Ship 
Production . November 1996, page 257. 

Refer to Chapter 8.3, Glossary and Abbreviations. 
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changing the timing of design transition from government to industry'. Traditionally, the Navy controlled the design 
through contract award: at which lime CDRL’s, militarv specifications, and GFE/GFM/GFl were transferred to llie 
shipbuilder. This method left shipbuilders little room for producibility and design improv ements. This approach 
has changed under acquisition reform. Now, design responsibility is transferred to industry as early as possible, 
following or even during concept design. Instead of v eiy^ specific design requirements, current requests for proposal 
(RFP’s) prov ide industry with perfonnance specifications and concepts of operations aimed at coirmiunicating the 
nature of the problem to be solved., .not tlie solution. Tlie premise of reform is to allow industry to examine the 
needs of government and react to those needs with products not bounded by bureaucratic constraints or government 
design specifications. The goals are the reduction of government design and management overhead required for 
centralized design control and to provide industrv with the incentiv e to seek iimov ative solutions that take adv antage 
of technological and manufacturing strengths. 

From a cycle time view, acquisition refonn should reduce design time by setting specific schedules in the 
RFP for competing industries (as opposed to a single organization, the Navy, producing the design.) Tlius, failure of 
one entitv' to meet the timeline will result in their loss of the contract, not the lengthening of the process. 

Additionally, the transfer of the design earlier in the process will result in less total infonnation being transferred 
(tlius, less chance of error) and open lines of communication at a time when concepts and requirements arc much 
more negotiable. 

To facilitate acquisition reform, a number of specific process innovations are being incorporated. A primarv’ 
mechanism is the introduction of Integrated Product and Process Dev elopment (IPPD)/lntegrated Product Teams 
(IPT) By IPPD/IPT, multi-disciplinar\’ teams (representation of all potential elements of design and production 
with customer participation is mandatorv) examine all aspects of the design process (requirements, technologv' 
alternatives, cost, ILS, manmng, etc) in an environment that promotes communication. The metliodology builds on 
the notion that no single person is the ultimate expert. Wliether actual or virtual, collocation is critical to tlie 
process. Integral to IPPD/IPT is concurrent engineering'^. Conciurent engineering seeks to consider all life-cycle 
aspects from the earliest design stages Ihrougli manufacturing, deployment, operations and disposal. These 
techniques apply some basic principles; process orientation, team approach, empoweniient, and open 
communications, parallel development and customer satisfaction. Cycle time should be shortened as critical issues 
for production and support as well as pro's and con's of design options are resolved early in the process, when 
rework and design disruption do not impact the process as greatly. 

In addition to team and process approaches, the design cycle is being improved by the introduction of 
improv ed data management and analysis. The use of 3D Product Modeling'^ seeks to integrate 3D geomelrv'. 
associativ e and parametric relationsliips and non-geometric information into a single model to be employed from 
concept design through ultimate ship disposal The model acts as the repository' for ship design and production 

" Sinunons, Assessment of Options for Enliancing Surface Ship Acquisition, Institute for Defense Analyses. March 
1996, pg. 39-40. 

Baum and Ramakrishnan, "‘Applying 3D Product modeling Technologv' to Shipbuilding”, Marine Teclmology' , 
Januarv 1997, pg. 56. 
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informatioru and integration of logistics and life-cycle data. The model facilitates inputs and outputs for all design 
analysis including cost and mission effectiveness, engineering assessment and producibility. An example of a 
generic product model is shown in Figure 2. The model enables virtual en\ironment design re\iew s, virtual 
shipvnrds, and simulation-based design. Non-geometric data is placed in a relational database svstem. 3D solids 
and surfaces are defined once with geometiy modeling and parametrics and linked to multiple locations with an 
associati\ity feature. The design is stored in a heterogeneous distributed database managed by a relational database 
product data manager (PDM). Users establish design rules (analysis tools, design parameters, constraints) fi-om 
which the design is automatically generated.. .when rule violations occur, the user is notified and prompted to 
resolve conflicts. Ultimately, a series of 3D Product Models for various ship designs could form a “Know ledge 
Base’' from which future designs could be rapidly developed. 



A key feature of a 3D product model is the capabilitv to facilitate Simulation-Based Design (SBD)^*^. SBD 
allow s designers to assess technologv^ insertion and design concepts in the virtual environment using Virtual Realitv' 
(VR), very large complex database svstems. optimization techniques, complex data visualization. Artificial 
Intelligence (AI) and liigh performance networking. SBD realizes cost savings and performance enhancements 
tlirough Modeling and Simulation (M&S) of design options (vice physical prototype construction) followed by 
direct extraction of production instructions (C AD/C AM/C AE^^) from virtually tested designs. When fully realized, 
3D modeling and SBD will allow dynamic model interactions of design parameters among the major design 
participants (Program Manager. Mission Analyst, Nav’al Arcliitect, Mechanical Specialist. Purchasing Agent. 
Arrangement Specialist. Structural Specialist, Production Specialist, Operational Personnel. Manufacturing 
Specialist), and utilize these relationships to perform all required concept analysis (Mission Analv sis, Mechanical 
System Analysis, Sliip Arrangement Scenario. Operational Simulation, Coupled Hydrodynamic/Structural Analysis, 


Ibid., pg. 56-65. 

Polini, Wooley, Butler, “Impact of Simulation-Based Design on Today's Shipbuilders”, Marine Technology , 
January^ 1997, pg. 1-9. 

Tibbitts and Keane, “Making Design Everybody's Job". Naval Engineers Journal, May 1995, page 283. 
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Manufacturing Simulation, and Cost Analysis) in a virtual env ironment. The impact on design cy cle time should be 
the ability to rapidly test design concepts and resolve design concerns prior to expenditure of time and resources on 
physical protot>pes. 

Tliese reforms, though certainly more refined, are not entirely without precedence. Early design hand-off was 
first used during TPP. IPPD mcthodologv' was implemented during the 1970’s for tlie FFG-7 program. Collocation 
and CAD technology was implemented during the DDG-51 and CG-47 programs. Total s\’sleni trade-offs of cost 
and performance have been in use to v ary ing degrees for several decades. Thus, the issue is now one of how much 
of each reform to implement, how will implementation impact ultimate performance and cost, and will external 
forces negate the gains brought about by reforms? 

These questions are especially important in hght of the long duration of design programs. For instance, 
typical dmations for combatant sliips can exceed 12 years: tvpical weapons s> stem programs require 15 years for the 
production item, and official DoD timelines (satisfying all program requirements) can exceed 22 years.^^ Those 
programs that hav e undergone the reforms of the last 10 years hav e yet to produce quantitative results satisfactory’ 
for analysis of improvement effectiv eness: ‘'There are good, although anecdotal, examples of this foundation 
actually being propagated in the field for our major programs.^ " Is there a way to test and optimize improvements 
prior to implementation? 

Consider the traditional project management methods listed in Tabic 1. These methods focus primarily on 
operational issues necessaiy to define project work structure, resource availabilitv and requirements, and budget 
requirements and allocations. Tlie methods are becoming increasingly mature w ith dev elopment of software suites 
like Microsoft Project®, At-Risk® and DoD ICOM (Input, Constraint, Output and Mechanism) packages. The 
approaches assume a well ordered project that progresses in vvcll-dcfincd stages to completion. In particular, the 
techniques assume a linear, or, in the case of PERT/ICOM, limited feedback process. Process improv ements can be 
intimated and assessed by examining the risk-benefit of options or by in depth analysis of Critical Paths in the 
process. However, this analysis often fails to detect systemic impacts of a giv en process improvement or realize 
strategic goals for improvement processes.At issue is the inability of these methods to capture decision process 
logic, political/social factors, workplace environment and other human factors. Additionally, their static nature 
cannot capture dv namics like schedule pressure, workforce experience shifts or rew ork issues. System dv namics 
can provide a methodologv’ to capture these issues and provide the strategic analysis neccssarv^ to optimize process 
improvements. 


Ryan and Jons, “Improving the Ship Design, Acquisition and Construction Process". Association of Scientists and 
Engineers. 28^ Annual Technical Symposium. 11 Apnl 1991, page 11. 

^ Dr. Paul Kaminski, Under Secretarv’ of Defense (Acquisition and Tcchnologv), inten iew in Program Manager , 
Januaiy-Februarv’ 1997, page 12. 

Rodrigues and Bowers, “System Dynamics in project management: a comparativ e analysis with traditional 
methods". System Dynamics Review , Volume 12 number 2. Summer 1996. page 124. 
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Technique/Tool 

Purpose 

Work Breakdown Structure (WBS) 

Basic definition of the project work. Precedes the 

project schedule and cost estimates 

Gantt Charts 

Representation of project schedule, may show' 

simple precedence relationships 

Project Network Techniques; PERT. CPM. PDM, 

GERT 

Analysis of scheduling impacts based on precedence 

relationships, cost estimatioa resource allocation. 

management and risk analysis, and input-output 

relationships 

Dynamic Strategic Plamiing (DSP) 

Cost benefit analysis incorporating risk 

relationships of net present value (NPV) for options 

against the customer utility' for those options 


Table 1 Traditional Project Management Techiques^^® 


System dynamics has been successfully applied to strategic project management for many decades. Since 
1964, dynamic models ha\ e been applied to projects ranging from naval construction (1980 Litton-lngalls 
Shipbuilding Litigation model) to large-scale DoD software de\ elopment projects."^ Tliese models have accurately 
identified key causes of process degradation including interdependencies created by process concurrence, impacts of 
project scope change, and relationship of schedule pressure to producti\ity. 

Recently, several d>Tiamic models ha\'e been created to address the issue of strategic process improvement in 
private shipyards. The McCue Production Model (MIT 1997"") demonstrated the impact of manpower fluctuations 
on producti\ it> and cost for Bath Iron Works and Ingalls Sliipyard. The focus of the McCue model on manpow er 
loading pro\ides tremendous insight into tlie necessiU' to mamtxiin w orkforce levels, even in light of short-term 
economic loss, in order to maintain the agility necessar\ to compete for emergent contracts. Tlie Simulation of New 
Acquisition Processes (SNAP) program (DDl 1997"^) bridges the gap between s>'sleni dynamics models and 
operational methods b\' demonstrating the dynamic flow of ship\ ard work against changing resource availabiliU’, 
persomiel productivity and schedule pressure. Tlie model is especially useful because it incorporates ship work 
breakdow n structures familiar to shipyard managers... thus, instilling a higli level of confidence in tlie results of 
process anah sis. Models are also being applied to other na\'al process issues such as operations and support costs. 


Ibid., page 121. 

Richard de Neufv ille, Applied Systems Analysis: Engineering Planning and Technology^ Management . McGraw- 
Hill Inc, 1990. 

Rodrigues and Bowers, “System D\ namics in project management: a comparath e analysis with traditional 
methods'’, System Dynamics Rc\iew , Volume 12 number 2, Summer 1996, page 128. 

"" Timothy McCue. 'The D> namics of Na\ al Shipbuilding-a Systems Approach", Tliesis for Massachusetts Institute 
of Technology, June 1997, 

Alfeld, WiDdns and Pilliod. "The Virtual Shipyard; A Simulation Model of the Shipbuilding Process", The 
Society of Naval Architects and Marine Engineers. April 21-23, 1997. 
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naval forces requirements and cost optimization''^, and the interaction of DoD acquisition programs'^. The effect of 
this effort is the increased application of system dynamics as a tool to assess and optimize process improvements 
from the strategic level. However, there has not yet been a significant mo\^e to apply simulation models to the 
design process. 

A, Unacceptable cycle time trends have lead design managers to implement many process 
improvements aimed at reversing these trends. However^ insufficient time has passed to determine the 
full effectiveness of these improvements, 

B, Given the duration of the design process and the lack offidelity in traditional project management 
methods to strategically analyze effectiveness^ system dynamics should be applied to naval design to 
provide a means of: 

1, Analyzing the causes of cycle time gronth 

2, ** Gaming*' potential process changes to determine effectiveness and relative risks. 


1.1.2 Requirements and Design Performance 

Like the problem of cycle time trends, performance issues are an increasing concern to w arfighters and 
designers alike. Requirements assessment is seeing significant introduction of new techniques to assess risk and 
effectiveness long before the laying of steel or the programming of weapons software. 

‘The modem warship (is the) most complex machine devised by man."'^ Their complexity crosses e\’er>' 
discipline of modem engineering and physics from fluid dynamics to computer network design to nuclear 
engineering. The complexiK is further increased by the dynamic interactions of these unique disciplines resulting in 
the integration of a single system. The ad hoc optimization process, which creates this s>’stem, is based on 
compromise and tradc-off of \'arious requirements and system options. However, with ever grow ing design 
complexity comes an increasingly unanswerable question: has the optimal solution been achie\'cd? Resoundingly, 
the answer is no, and the difficulty is translating operationally required mission effectiveness into optimized design 
parameters. 

Until recently, mission effectiveness was defined qualitatively. Performance requirements were pro\'ided to 
designers, but the operators had few means to quantitatively assess the effectiveness of such requirements, and 
designers were provided little room or guidunce to trade requirements and cost. For example, requirements would 


Towles, Rocholl, Jeffers and Platt, “Force Affordability Modeling; the EH namic liw estmcnt Balance Simulation 
(DIBS)", presentation to Naval Surface Warfare Center (Tarderock Division, Bethesda. MD, April 15, 1997. 

Towles, Rocholl, Jones, Jeffers and Platt, “System Wormliole Analysis Tool (SWAT): a Simulation Based 
Acquisition Initiative," presentation to Na\'al Surface Warfare Center Carderock Di\ision, Bethesda, MD, October 
27, 1997. 

Gale and Scott. "Early Stage Ship Design Seminar", Society of Naval Architects and Marine Engineers, October 
1995. 
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state “cany out anti-submarine operations in the North Atlantic^’ or "maintain X knots in sea state 5/'“ Such 
statements are misleading to both requirements setters and designers. The first, more general statement, does not 
indicate any level of trade-off or even a notion of what “anti-submarine operations” might entail. The designer is 
forced to assume an engineering definition and may inevitably misinterpret the operators' true intentions. The 
second, more specific requirement remov es all potential for tradc-off against other variables, and does not allow 
alternate solutions to tlie problem. Under these circumstances, designers are often detached from customers 
(operators), and are forced to make critical decisions without explicit feedback until the sv stem is operational. 

For the designers, there is a lack of clariU’ as to who the customer is:"^ the operator, the sliip builder or just 
the next designer in the design chain. There is a tendency to under-fund R&D efforts and requirements setting 
processes which would allow both designers and operators to reach better optimized solutions. Tliese factors 
combine to add confusion and delays to the requirements setting process. 

Requirements setters within the operating forces of the Navy (OPNAV), are frequently focused on details and 
fail to communicate “big picture” needs. Turnov er is also rapid and OPNAV personnel may be transferred before 
they understand and appreciate the problem.“^ Additionally, the customer lacks understanding of the ship design 
process. Specifically, the fleet operators aren't able to understand how specific requests for performance translate 
into design trade-offs. 

When performance changes are requested (due primarily to out-of phase dev elopment programs and 
conflicting requirements at v arious stages of design definition^^), the resulting disruption to the design process is 
significant. For instance. Table 2 shows how design priorities changed over the course of the DDG-51 preliminarv^ 
design effort. Customer prioritv’ changes, particularly with respect to eiiergv’ conservation, resulted in a large design 
effort (culminating in several design variants and two independent design studies^") to analv-ze designs vv liich 
incorporated the RACER (Rankine Cycle Energy Recover} ) propulsion sv stem. However, total ship sv stem impacts 
of RACER and program risks related to the RACER R&D schedule (not in phase with DDG-51) ultimately resulted 
in cancellation of the RACER integration with DDG-51 and a further realignment of performance priorities (highest 
to lowest) in the DDG-51 contract phase to^^ 

a. Combat sv stem capability 

b. Speed and endurance 

c. Survivability’ 

d. Habitability’ 


Dav id Brown. “Naval Arcliitccture”, Naval Engineers Joiunal . Januarv’ 1993, page 43. 

Ibid, page 2-22. 

Roger Home, Improving the Ship Design, Acquisition and Construction Process: Strategic Plan , Naval Sea 
Systems Command, Washington DC, June 1991, page 2-20. 

Ibid, page 2-21. 

Ibid, page 2-21. 

Andy Summers,, PPG 51 Guided Missile Destroyer Preliminary Design Historv’ , Naval Sea Systems Command, 
June 1984, page B-1, 

Andy Summers, PPG 51 Guided Missile Destroyer Contract Design Historv , Naval Sea Systems Command June 
1987, page 3-1. 
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e. Design fleMbility and growth potential 

These changes lead to further delays and generated additional iterations of the DDG-51 design.Changing 
prionties, unclear requirements relative to total s> stem impacts and out of phase de\ elopment programs generate 
design effort. 


Attribute 

Priority at Start 

Priority at Finish 

Combat Capabihty 

High 

High 

Acquisition Cost 

High 

Medium High 

Operability 

Medium Higli 

Medium 

Passive Survivability^ 

Medium High 

High 

Energy Consen^ation 

Medium High 

High 

Future Growth Flexibility 

Medium High 

Low 

Active Survivability 

Medium 

Medium Higli 

Ship Displacement 

Medium 

High 

Manning Reductions 

Medium 

Low 

Habitability 

Low 

Medium High 

Minimum Risk 

Low 

Low 

Standardization 

Low 

Low 


Table 2 Preliminar> Design Priorities at Beginning and End of Design Phase^^ 

As a result of the noted shortcomings (dating back to tlie late 1980's), the DAC study^^ and other process 
improvement efforts such as Secretar\' of the Navy Instruction 5000.2B^ , tlie requirements process now institutes 
improved performance assessment mechanisms. Tliese mechanisms provide for structured input of requirements, 
assessment of engineering solutions with respect to those requirements and feedback from operators regarding 
sv stem solution options. Some of these improv ed methods include Qualitv’ Function Deployment (QFD), Analvlical 
Hierarchy Process (AHP), and Genetic Algorithms.^^ 

The QFD method, vv hich was devised by a shipvard in Kobe. Japan to address the same problems relative to 
Its customers, provides a structured process of taking customer needs (stated in the subjective, qualitative and non¬ 
technical '‘v oice of the customer") and translating those needs into “corporate language" (quantitative and technical 


Verne Stoilz, “DDG-51 Cost Estimate Log", Nav al Surface Waifare Center Carderock Div ision, Bethesda, MD. 
October 1984 

Andy Summers., PPG 51 Guided Missile Destroyer Preliminary Desian History , Naval Sea Systems Command 
Jime 1984, page 3-1 and 3-3. 

Ibid, page 2-16. 

John Dalton, Implementation of Mandatory^ Procedures for Major and Non-Maior Defense Acquisition Programs 
and Major and Non-Major Information Technology Acquisition Programs (SECNAVINST 5()0().2B) , Department of 
the Navy, Washington DC, December 6, 1996. Appendi.x II. 

Defense Acquisition Deskbook Joint Program Office, “Defense Acquisition Dcskbook Version 2.3.101", Wright- 
Patterson Air Force Base, Ohio, March 31, 1998. 
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parameters required by designers. The customer traits are commonly referred to as Measures of Effectiveness 
(MOEs) while design performance attnbutes are Measures of Performance (MOPs). QFD pro\ides a qualitative 
mapping from MOEs to MOPs. The two ‘‘languages” are translated \ia a matrix referred to as the “House of 
Quality” (see Figure 3 below.) Tlie mapping highhghts s>nergies and conflicts between design options and 
competing customer requirements. As a result, customers and designers can visualize design trade-offs and propose 
alternative solutions. The process is iterative and its greatest use is as a means to facilitate communication between 


customers and engineers througlioiit tlie design process. The metliod has proven useful in Na\y programs ranging 
from tlie Joint Advanced Strike technolog>^ (JAST) program to the Next Generation Carrier Program (CVX.)*^^ 



Figure 3 Quality Function Deployment "House of Quality"^^ 


Tibbitts and Keane, “Making Design E’vervbodv's Job”, Naval Engineers Journal. Mav 1995 , page 287. 
Ibid, page 287. 

International TechneGroup Incorporated (ITI), http://w\\w iti-oh.com/cppd/qfd/qsoft.htm. 
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Whereas QFD is a qualitative method of communicating performance attributes. AHP aims to quantifS’ 
perfonnance attributes in a manner which allows designers to search a boarder solution space while still meeting 
fundamental performance needs. Specifically, requirement setters and engineers establish a well defined mutually 
agreed to set of performance attributes and tlie quantifiable values of those attributes. The requirement setters then 
w eight tlie attributes tlirough a series of pair-wise comparisons. The result of such comparison is a vector of 
weigliting factors relating the '‘goodness” of each attribute against another. Thus, engineers can explore the entire 
solution space and determine the optimization of customer needs within that space. An example of this method of 
has been to quantify variables ranging from producibilit}’ of ships to life-cycle cost to combat perfonnance.^*' In this 
example, subject-matter experts were questioned regarding a number of performance attributes. Those attributes as 
well as the weighting factors for a number of ship t>pes (Destroyers and Carriers) are shown in Table 3 below. 

Using the AHP method, a designer would 

a measure the attribute values (MOPs) for generated s\ stem designs (such as sustained speed is 20.1 
knots or 25.6 knots), 

b. normalize the MOPs against previously agreed goal and tlireshold \ alues (such as 20.1 is 0.014 and 25.6 
is 0.80 to a goal of 27 knots and a threshold of 20 knots) or ask customers to re-evaluate design 
attributes directly by additional pair-wise comparison (to generate a summaiy’ values from 0 to 1 for a 
parameter hke modularity), 

c. multiply normalized MOPs times the weightings for each parameter which in turn generates top-le\’el 
MOEs for each attnbute category (such as 0.8 times 0.3174 is 0.2539 for speed and the total of all MOPs 
for Operational Capability adding to a value such as 0.112), 

d. then sum the MOEs to determine an 0\'erall Measure of Effectiveness (OMOE) value for each design 
(such as design 1 is 0.23 and design 2 is 0.45)...the liighest OMOE design is the optimal customer 
directed design relative to the other scored designs. 


Wilkins. Kraine and Thompson. “Evaluating the Producibility^ of Ship Design Alternatives". Journal of Ship 
Production, August 1993, page 196-201. 
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Ship Performance Criteria 

DD 

CVN 

Operational Capabilitv^ 

0.5971 

.07009 

Payload Carrving Capacitv' 

0.1293 

0.0666 

Payload Effectiveness 

0.3030 

0.3252 

MobiliW 

0.1194 

0.0362 

Speed 

0.3174 

0.4444 

Endurance 

0.5110 

0.4444 

Maneuv'erability' 

0.1716 

0.1111 

Availability 

0.2516 

0.1814 

Survivability 

0.1967 

0.3907 

Operational Efficiency 

0.2106 

0.2020 

Manning 

0.3768 

0.7142 

Habitability’ 

0.2066 

0.1429 

Safety 

0.4166 

0.1429 

Future Growth Margin 

0.1924 

0.0971 

Weight Margin 

0.2460 

0.3214 

KG Margin 

0.1582 

0.3214 

Volume Margin (density ) 

0.2060 

0.3214 

Modularity 

0.3898 

0.0357 


Table 3 Ship Performance Weighed by Analytical Hierarchy Process Methodology^^ 

The previous methods provide both a means to define customer needs relative to designer attributes and 
trade-off specific designs against each other in a structured enviromnent. Genetic algorithms provide the fmal step 
in s\'stem performance optimization by systematically enabling designers to search a liiglily non-hnear design space 
for tlie overall optimal solution relative to the user defined OMOE. Specifically, genetic algorithms take a series of 
design parameters or “genetic materials" (such as LBP, a series of discrete combat systems suites or various hull 
material mixes), generate designs from those genes, assess the OMOEs for the resulting designs, “mate" tlie designs 
with each other to generate new “generations" of designs, introduces “mutations" to a limited number of the genes in 
each generation, and continues the process until the design no longer improv es or “evolves." Traditional AoA 
metliodologv^ derives optimization of the design space tlirough directed exploration of an overlv' large number of 
design alternatives. Such exploration is only possible using design svmthesis tools like the Adv anccd Surface Ship 
Evaluation Tool (ASSET). Such tools allow a small team of designers to rapidly develop and balance a large 
number of sliip alternativ es. For example, the current CVX program is exploring design in three stages (ainving size 
and composition alternatives, propulsion alternatives and s>'stem alternatives) with as many as 30 designs per stage. 


43 


Ibid, page 200. 
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Past explorations using design synthesis programs like DD()8 and ASSET ha\ e generated as man\' as 1000 different 
ship designs in an effort to ensure an optimum solution.*^^ However, e\ en with s>Tithesis tools, much the design 
work is still manual, such as topside arrangement of a combat s\'stem suite or flight deck design in a CAD 
environment. As such, designers still must approach tlie analysis of the solution space as an “experimental design”, 
which is linear. Given the increasing complexity’ of current designs and the time required to generate a single 
design, it is necessary to have a method like genetic algorithms to ensure not only local, but global optimization of 
the solution. As the design space is highly non-linear, sub-optimized solutions are often pursued (see Figure 4.) 
Genetic algorithms can avoid such occurrences by not focusing the search in a linear manner (as with by a staged 
AoA approach) but evolving beyond local optima to achieve the peak solution. The use of such approaches are 
proving successful both in academic pursuits of design (Mark Tliomas and Allan Andrew theses) and activ e 
programs (Joint Strike Fighter Program use of SNAP'^^). 

Performance and the sy stematic optimization of performance is a key concern to operators and designers 
alike. However, the customer oriented methods of QFD and AHP, along with the optimization techniques of AHP 
and Genetic Algorithms, provide means to ov ercome past concerns. The Navy is beginning to apply these 
techniques with success.. .but the question remains whether these successes are enhancements to design performance 
alone, or whether tlie dy namic impacts of performance enhancements will result in cost and cycle time growth. 

These impacts will be addressed further in Chapter 2. 


Myron Ricketts, Manual for Naval Surface Ship Design Technical Practices . Nav al Sea Systems Command 
Washington DC, 1980, Volume 1, page 5-35. 

Alfeld and Shepard, “SNAP-Simulating New Acquisition Processes". CAIV Workshop. Decision Dy namics INC, 
11-12 July 1997. 
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Evolutionary Strategies 
will find the best solution 
within the solution space 


Multiple Local Optima 

Large Flat Areas 

Non-optimal solutions 

Even when the 
landscape changes 


Figure 4 Optimization and Genetic Algorithms^* 


1.1.3 Cost 

In addition to the need to achieve required performance within a constrained schedule, modem warships must 
also be cost effecti\ e. The cost of ships has been steadily increasing, well above obvious increases due to inflation. 
The DAC stud\^ shows an alanning growth trend. Average combatant ship acquisition cost in equiv alent dollars 
(nonnalized in the stud\' to FY90) has increased linearly over 800% per vessel over a thirty year period."*^ This trend 
alone, has represented the single most critical factor driving the need for acquisition refonn. As such, strategic cost 
analysis and cost analysis tools hav e received sigmficant emphasis in the last decade. 

There are a multitude of reasons for this trend. Consider the list of cost roadblocks disclosed during the DAC 
Study (Table 4). Many of the listed concerns (constmetion delays from late design changes and GFE/GFI, lack of 
shipbuilder producibilih* inputs, and failure to fully explore design options prior to preliminar\' and contract design) 
ha\ e already been noted as equal problems related to schedule and perfonnance. 


Ibid. 

Ryan and Jons, ‘Tmproving the Ship Design, Acquisition and Construction Process’, Association of Scientists and 
Engineers, 28^ Aimiial Technical Svmposiuin, 11 April 1991, page 11. 
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• Too many changes after contract award 

• Requirements setting without rigorous cost-benefit analysis 

• Lack of cost awareness or cost analysis capabiliK organic to the design communit\^ 

• Inefficient shipbuilding practices 

• Awards based on unrealistic, low bids 

• Late delh eiy' of GFI/GFE 

• Labor intensive ship designs 

• Insufficient production and future growth margins 

• Lack of system architecture to accept change 

• Out dated specifications, practices and margins 

• Under-funding of Concept Design Phases 

• Increasing complexity and cost of combat systems 

• Excessive costs associated w ith prograimnatic documentation 

Table 4 DAC Study Cost Roadblocks^^ 

The most noteworthy cause of cost growth in naval design is the failure to leverage the relationship betw een 
cost and time. Consider Figure 5. In the early stages of design, decisions are made that define the general 
characteristics of the sliip. Those initial decisions hav e not traditionally incurred large costs (i.e. concept design 
funding has been hmited), but they do produce future costs by the definition of specific sliip design choices. For 
example, the result of concept design may indicate the desired vessel to be a destroyer, approximately 465 ft long, 
6800 Iton hglit ship displacement, capable of 30 kts sustained speed using 4 LM-2500 engines, with 350 personnel, 

1 5’754 DP Gun, 96 VLS cells and the Aegis weapon svstem centered aroimd the SPY-ID radar svstem. The 
description does not provide enough detail to construct a ship, but it is good enough to estimate acquisition cost to 
within 80% probabiliW of accuraev'. The reason is that historically, the above factors will result in 80% of the total 
cost of the ship. As the design process matures, greater design detail is expressed, incurring greater costs through 
increased design effort and ultimately, construction. However, this detail does not create substantial changes in end 
cost. For our example, later design stages may change the length to 466 ft, the deckhouse may be constructed from 
steel vice aluminum, and the scantlings in the double bottom may be increased for increased defense from 
underwater explosions. Hovvev'er, these changes will not result m significant cost changes beyond the initial 
estimate. This fact will be increasingly important with respect to combat system impacts on cost (discussed below). 
Tlius, the levels of cost "lock-in" and cost inciured are inversely proportional. 
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Ibid., page 14. 
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Figure 5 Key Transitions in the Design Process 

This relationsliip can be further demonstrated in the methods of managing weiglit and weight based costs 
during the design process. Consider a typical trend for weight and KG demonstrated in Figure 6. Despite short-term 
fluctuations, the overall trend (indicated by the included trend line) is that of exponentially decaying growth towards 
a final value, namely, the light sliip weight at launch. It is necessary' that convergent behavior in all aspects of the 
naval design exist. Otherwise, it would be impossible to detenuine whether the completed ship would function 
desirably as a s\ stem (i.e. float and float upriglit.) It is likewise expected that tlie values for properties such as 
weight. KG, electrical load, etc. at the beginning of contract design will be exceeded during detailed design: and 
even further exceeded during the expected life of the ship. As the design matures, assumptions regarding sy stem 
weights, locations, scale, etc, arc refined. To err conservatively, the assumptions are adjusted with margins to reflect 
potential growth. Margins arc added to those system v alues (weight. KG, powering, etc.) that are critical to ship 
performance. Table 5 shows weight and KG margins used for the design naval surface combatants. These margins 
are considered the minimum additional weight or moment-arm that should be included in a design to account for 
uncertainty in assumptions. At the conclusion of a design phase, the design managers may choose to reduce or 
eliminate margins from previous stages as the level of confidence in the current design values (reflectiv e of the lev el 
of detail achieved) is increased This trend is displayed for the DDG-51 program in Figure 7. 
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Weightand KG Trends 



Figure 6 DDG-51 Contract - Detailed Design Weight and KG Trends^^ 


Weight and Weight Margin Trends 



Figure 7 DDG-51 Detailed Design Weight Margin Trends^^ 


Mike Jeffers. Inler\ ie\v at Naval Surface Warfare Center Carderock Division. Bethesda, MD, No\ ember 12, 1997. 
Ibid 
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Weight Margin 

Mean % 

Mean Plus Standard Deviation % 

PD/CD Margin 

0.83 

4.36 

D&B Margin 

1.71 

5.29 

C. MOD Margin 

0.33 

1.43 

GFM Margin 

0.33 

1.20 



12.28% 

KG Margin 



PD/CD Margin 

2.67 

6.09 

D&B Margin 

1.87 

4.97 

C. MOD Margin 

0.18 

1.12 

GFM Margin 

0 

0.34 



12.52% 


Table 5 NAVSEA Design and Life Cycle Margins^' 


As regards cost, it is important to consider the trends of design resulting from margins and convergent design 
because the traditional methods of determining cost rely hea\ ily on w eight and major system selections. 

Specifically, traditional acquisition cost estimates during design are determined using parametric analysis of weights 
(from Sliips Work Breakdown Structure (SWBS) groups) for similar ship t}pes of the past. Table 7 shows top-level 
SWBS groups considered in early ship design and cost analysis. Tlie SWBS groups represent an accounting method 
tliat prov ides means to estimate features of the ship (such as weiglits and distribution of weights for structures, 
support s} stems, etc) tliat caimot be explicitly defined during early design. Cost estimating relationships (CER's) are 
applied to the SWBS w eights to determine cost estimates. These w eight-based cost estimates may be adjusted for 
specific shipyards, known s>'stem costs, learning curves associated with multi-year contracts (Figure 9), and other 
reasonable cost impacts. Generally, the result of the estimates determined in this mamier should follow behavior 
similar to the weight behavior of Figure 6, i.e. the estimate should conv erge. During later design stages, small 
transfers of w eight from one SWBS group to another iv \y result in substantial first order cost impacts. These 
impacts can be forecasted early in the design process througli sensitivity analysis of the parametrics (Table 6.) 

How ever, the second order cost impacts due to disruption, transitions within SWBS groups and multi-ship schedule 
shifts are not disclosed with weight-based costing^". Although these impacts are usually v\ ithin 20% of the 
parametrically determined values, they can grow to lev els of well over the initial cost.^^ That has been a criticism of 
such cost methods. There is a need to improv e the methodology of weight-based costing to be responsiv e to second 
order effects, or new methods must be used. 


Reuven Leopold, Manual for Nav al Surface Ship Design Technical Practices , Naval Sea Systems Command, 
Waslungton DC, 1978, page 4-157 

Kenneth Cooper, Naval Ship Production: A Claim Settled and a Framework Built, Pugh-Roberts Associates, 
Cambridge, MA, December 6, 1980. 

Prof Alan Brown, interview May 11, 1998, Massachusetts Institute of Technologv, Cambridge, MA. 
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Ship Work Breakdown 

Structure 

Program Cost 

(FY 83 S/lton) 

100 Structure 

17,500 

200 Propulsion 

110,800 

300 Electric 

180,200 

400 Command 

46,300 

500 Auxiliary 

80,800 

600 Outfit 

78,500 

700 Armament 

16,000 


Table 6 CostAVeight Sensiti\ity^‘‘ 


SWBS 

Description 

SWBS 1 Description 

100 

Hull Structures 

500 

Auxiliary Systems, General 

110 

Shell and Supporting Structure 

510 

Climate Control 

120 

Mull Structural Bulkheads 

520 

Sea Water Systems 

130 

Hull Decks 

530 

Fresh Water Systems 

140 

Hull Platforms And Flats 

540 

Fuels and Lubricants.Handling and Storage 

150 

Deck House Structure 

550 

Air.Gas and Misc Fluid Systems 

160 

Special Structures 

560 

Ship Control Systems 

170 

Masts, Kingposts. And Service Platforms 

570 

Underway Replenishment Systems 

180 

Foundations 

580 

Mechanical Handling Systems 

190 

Special Purpose Systems 

590 

Special Purpose Systems 





200 

Propulsion Plant 

600 

Outfit and Furnishings,General 

210 

Energy Generating System (Nuclear) 

610 

Ship Fittings 

220 

Energy Generating System (Nonnuc) 

620 

Hull Compartmentation 

230 

Propulsion Units 

630 

Preservatives and Coverings 

240 

Transmission and Propulsor Systems 

640 

Living Spaces 

250 

Propulsion Support Systems (Except Fuel and Lube Oil) 

650 

Service Spaces 

260 

Propulsion Support Systems (Fuel and Lube Oil) 

660 

Working Spaces 

290 

Special Purpose Systems 

670 

Stowage Spaces 



690 

Special Purpose Systems 





300 

Electric Plant, General 

700 

Armament 

310 

Electric Power Generation 

710 

Guns and Ammunition 

320 

Power Distribution Systems 

720 

Missies and Rockets 

330 

Lighting System 

730 

Mines 

340 

Power Generation Support Systems 

740 

Depth Charges 

390 

Special Purpose Systems 

750 

Torpedoes 



760 

Small Arms and Pyrotechnics 



770 

Cargo Munitions 



780 

Aircraft Related Weapons 



790 

Special Purpose Systems 





400 

Command and Surveillance 

800 

Engineering 

410 

Command and Control Systems 

812 

Change Proposals, Scoping, Checking 

420 

Navigation Systems 

813 

Planning & Production Control 

430 

Interior Communications 

831 

Construction Drawings 

440 

Exterior Communications 

835 

Engineering Calculations 

450 

Surface Surveillance Systems (Radar) 

838 

Design/Engineering Liason 

460 

Underwater Surveillance Systems 

839 

Lofting 

470 

Countermeasures 

841 

Tests & Inspections. Criteria & Procedures 

480 

Fire Control Systems 

844 

Combat Systems Checkout Procedures 

490 

Special Purpose Systems 

850 

ILS Engineering 



897 

Project Management 


Table 7 Ships Work Breakdown Structure 


Hope and Stortz, "Warships and Cost Constraints", Naval Engineers Journal . March 1986, page 45. 
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Another particular concern is the increased dominance of combat system costs compared to overall ship costs. 
Consider the trends shown in Figure 8. The combat system cost fraction for both combatants and amphibious ships 
are steadily increasing. In the years during and following World War IF combat sy stems consisted primary of high 
densit>\ hea\'y-\veight gun s>stenis. The primary^ integration issues (and thus cost and system trade-offs) were gun 
placement and provision for adequate displacement to support those guns and their amnumition. The USS Atlanta 
(CL-51) is representative of such designs (Table 8.) Its combat system suite is consistent with other World War II 
designs: low cost, low technolog>', and liighly redundant. The gun s> stems are manpower intensive, but the 
manpower is dominated by low skill, low cost gun handlers. The resulting ship has a relatively small fraction of 
acquisition cost dedicated to combat systems (less tlian 40%), and operations and support costs are dedicated to 
supporting a young, unskilled labor force. An intermediate generation of combatant ships (represented b\^ the DD- 
963 class) falls in the transition period for acquisition and design methodologies, TPP. The combat systems are 
more complex and more expensive as a fraction of the total cost, which also shows an increasing trend (Figure 9.) A 
ship designed by shipbuilders (Litton-Ingles Shipbuilding), it has greater total volume to accommodate improved 
producibility and acceptance of future system upgrades. As a result of these improvements and if not for the 
government induced cost over-runs (Chapter 1.1.1), tlie ship acquisition cost may have been comparable to the CL- 
51. Manpower is increasingly skilled in electronics, sensor management and other specialh' skills. As a result, the 
ship is not only increasing in combat systems cost, but also operations and support costs, which are dedicated to 
system maintenance and manpow er training. Tlie final generation of the combatant (DDG-51) is the epitome of 
current design and cost trends. The combat system is a veiy large fraction of acquisition cost. Artificial constraints 
imposed on displacement and length, coupled with requirements to elev ate large sensors on the superstructure, result 
in a ‘‘beamy”, dense ship that poorly incorporates producibility features.^^ Tlius, acquisition costs are undesirabh: 
higli. Crew growth coupled with further complexities in the combat sv stem suite require the most higlily skilled 
crews to operate and maintain. The result of these factors: DDG-51 has pushed tlie combat system cost and total 
acquisition cost trend to a critical level, and operations and support costs have exceeded reasonable budgetaiy^ levels. 


Phihp Sims, “Ship Impacts Studies”, Naval Engineers Journal . Mav 1993, page 87. 
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Ship 

Atlanta 

CL-51 

Spruance 

DD-963 

Arleigh Burke 
DDG-51 

Design Date 

1938 

1969 

1982 

Full Load (Iton) 

8440 

7800 

8300 

LBP (ft) 

530 

529 

466 

Beam (ft) 

53 

55 

59 

D10(ft) 

33.2 

42 

42 

Volume (ft^) 

700,000 

1,030,000 

971,000 

Vol to Wt (ft®/lton) 

82.9 

132.1 

117.0 

Crew 

626 

276 

318 

Combat Cost Fraction 

40 

47 

57 

Strike Weapons 

8 X 5’V38 

2 X 5’754 

Harpoon Missiles 

1 X 5754 

Tomahawk Missiles 

AAW 

40 & 20 mm Guns 

NSSM 

SM-2 

Sensors 

Small radars 

Small sonar 

Optical 

Medium radars 

Big sonars 

Towed array 

Big radar 

Big sonar 

Towed array 


Table 8 Comparison of Combatants over Time^^ 


RADM Roger B. Home, '‘Concept to Commissioning, Improving the Ship Design, Acquisition and Conslmction 
Process: Strategic Plan”, Naval Sea Systems Command, Washington, DC, June 1991. 

Philip Sims, “Ship Impacts Studies”, Naval Engineers Journal , May 1993, page 91. 
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Cost Comparisons of Surface Combatant Projects 



1970 1980 1990 2000 

Contract Award (FY) 

Figure 9 Basic Cost of Construction Trends for Surface Combatants^^ 

As a result of these trends, many cost control programs liave been implemented. First, weight-based costing 
has evolved greater fidelity. Tlie ACEIT (Automated Cost Estimating Integrated Tool) cost program is a Joint 
Seivace system pro\iding a suite of costing tools designed to assist analysts in arriving at cost estimates, conducting 
"what-if.^" studies, developing cost proposals and evaluations, conducting risk and uncertainty analysis, and 
dev eloping CER’s. Tlie program, developed and maintained bv Tecolote Research Inc., provides many 
improv ements ov er traditional weight-based approaches including"^^: 

• User defined WBS with capability to build one or more default WBS and associated definitions, 

• Ability of users to enter their own cost equations, access a built-in Methodology Knowledge Base, search 
for analogous data, or create CER's, 

• The calculation of basic learning curv^es, shifts, rotations, rate effects, simultaneous sensiti\ity/”vvhat-if?" 
analyses, quantity changes, adjust for Icad/lag times with methods for time phasing, and adjustments for 
design producibility, 

• Integrated interface (AACEI) with ship design s>'nthesis tools (ASSET) for real-time cost-design 
comparison. 


Colton and Company, hup.//vv^>v \\ coltoncoinpanv com , Arlington, VA. 

Defense Acquisition Dcskbook Joint Program Office, "Defense Acquisition Dcskbook, Version 2.2.87", Wright- 
Patterson Airforce Base, Da}1on, OH, December 15, 1997. 
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• All automated cost database (ACDB) with the capabiliU' to enter, search, and retrieve cost, schedule, 
technical, and programmatic data, including contractor raw data (mapping and normalizing cost data into 
standard WBS), 

• Cost analysis statistical package (COSTAT) performs statistical analyses including histograms and 
scatter plots, hnear, log-linear, and non-linear regression, and fit learning cuiv es, cost risk application 
(RISK) that performs nsk and uncertainty analysis. 

The immediate goal of tliese improvements is to provide ship design managers with robust acquisition cost estimates 
early in the design process, thus leveraging design trade-offs. However, ACEIT fits within the context of a larger 
movement in tlie DoD: the transition from acquisition costs and simple Life Cycle Cost (LCC) analysis to Total 
Ownership Costs (TOC.) 

TOC is the attempt to assess system cost beyond the boundaries of the specific platform (or ship.) In addition 
to LCC (R&D, acqmsition, operations and support and disposal costs), TOC seeks to include appropriate exiemal 
costs resulting from the development of the ship (i.e. training pipe-lines, repair facility and overhead combat 
systems, cost of a sailor, etc.) TOC is incorporated formally in the design process througli the methodolog>' of Cost 
as an Independent Variable (CAIV.)^^ Through the CAIV approach, early phases of the acquisition process (Pre- 
Milestone 1) establish an aggressive, achie\ able LCC goal based on mission requirements, reasonable deliveiy 
schedules, acceptable design baselines and expected budgetary' forecasts. At Milestone I, firm cost boundaries are 
established as well as goals for LCC reduction (the savings being reflected as TOC.) Design managers seek to 
optimize s\’stem cost, performance and schedule within tliis context. The key to achieving effecti\ e constraints and 
goals is the inclusion, early in the process, of all relevant life cycle participants. “The CX erarching IPT (OIPT) for 
each ACAT I and ACAT lA (as required) program shall establish a Cost/Performance IPT (CPIPT). The user 
community shall have representation on the CPIPT. Industry' representation, consistent with statute and at the 
appropriate time, shall also be considered.The inclusion of these participants at the earliest design stages 
provides cost estimators the ability to assess the impact on cost of critical design decisions such as producibilitv'. 
combat s> stem design schedules, integrated logistics support (ILS) and otlier LCC issues. Thus, important impacts 
can be tested in cost models like ACEff. 

Cost and the optimization of cost goals has dominated the reforms seen m the last decade, particularly as seen 
DoD directives (CAIV in DoD 5000.) The evolution of cost models along with greater inclusion of life cycle 
participants is allowing design le\ crage at the point of greatest effectiv eness, early design However, the question 
remains.. .will these enhancements effect only cost, or will the dvTiamic impacts of cost analysis result in 
performance degradation and cycle time growth? 


^ '‘DoD Directive 5000.2-R, Mandatoiy Procedures for Major Defense Acquisition Programs and Major Automated 
Information Svstem Acquisition Programs'’. Part 3 Section 3.3.3. 

Ibid. 
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1.2 Dynamic Modeling of the Design Process 


1.2.1 Need for Modeling 

The concerning trends reflected in the DAC stud\\ increasing costs and schedule with lack of system 
performance assessment, have received substantial focus and improv ement efforts. For cost, improved cost models 
and greater inclusion of life cycle participants have highhghted ‘‘stalking horses” that may be tamed to reduce costs. 
As for performance, greater customer focus within the context of improv ed system requirement and performance 
assessment provides better means to trade performance against factors of cost and schedule. Even cycle time may 
realize significant improvements with the inclusion of IPTs, evolving acquisition strategies, and computer based 
data management and assessment. However, imlike cost and performance, nav al design process time has not 
receiv ed mush effort towards the creation of robust, strategic assessment tools Naval design managers lack the 
ability to effectively trade-off schedule with process improvements. This shortcoming is important considering the 
three primary' v ariables: cost, performance and schedule. The difficulty in managing a successful program results 
from the fact that “...the vectors of these variables are higlily interdependent and non-linear. As noted 
previously, the improv ements to costing and performance naturally impact the schedule through inclusion of new 
design participants, increasing levels of desired design tasks early in the process or introduction of previously 
unused or unavailable assessment tools. 

Traditional project modeling tools, such as PERT and CPM do provide a tool for assessing the direct impacts 
of such changes, but often fail to capture critical feedback and dependencies witliin the engineering and production 
process.As a modeling technique, sv stem d\ namics can effectiv ely captme such non-linearity and, thus, provide 
better understanding of the modulations of the v ariables under consideration. With respect to project management, 
system dynamics has been prov en for numerous specific applications and cases.^ However, system dynamics has 
been primarily used for high level or verv^ specific decisions and often lacks sufficient structural detail to apply to a 
specific process (such naval design, 

A need has developed to provide program managers mth a dynamic process tool appropriately adjusted to 
reflect the realities of naval design* 


ADM WavTie Meyers (USN ret.), interview, Techmatics Inc., Arlington, VA, November 13. 1997. 

Rodrigues and Bovvers, “System Dynamics in Project Management; a Comparativ e Analysis with Traditional 
Methods”, System Dynamics Review , Volume 12 Number 2, summer 1996, page 130. 

Ibid, page 128. 

Ibid, page 133. 
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1.2.2 What is System Dynamics? 

System dynamics is rooted, like its founder Dr. Jay W. Forrester*®, in the engineering traditions of control 
theor>' and feedback analysis. Three characteristics distinguish system dynamics from traditional management 
support tools^^; 

• Its foundation is engineering science, not statistics, 

• It relies on data to support, not control model development, and 

• It presents a dynamic, not static, environment for decision analysis. 

Specifically, system dynamics empliasizes the construction of models that capture the process of a system based on 
explicit casual relationships of variables within a closed-loop feedback structure. Data is used to cahbrate the 
model, but the verification of a model relies on common sense (agreement of the operation of the real world and the 
model structure) and formal mathematics (accumulations and flows based in differential calculus.) The resulting 
model relies on complex, non-linear relationships to dictate behavior, rather than linear, statistically based 
associations. System d\ namics models still incorporate statistics during analysis as a means to test the sensitivity of 
model assumptions. But tliis analysis is intended to further validate the model rather than drive model development. 
Finally, model results are meant to be used as strategic tools to compare policy impacts, not produce explicit results 
(such as exact cost or a definitive time table.) A validated model, wliich demonstrates generally accurate behavior 
(v ariable fluctuations, chaiamic convergence or di\ ergence, and representative process structure) provides a means 
to assess policy options for '‘order of magnitude" relationships. 

System dynamics is widely accepted as an assessment tool. During the late 1950’s, Dr. Forrester, an MIT 
researcher responsible for the inv ention of random-access magnetic computer memorv, accepted a position with the 
Sloan School of Management. His interest w as the application of control thcorv' to social sv stems such as business 
and industrial processes. Since that time, his anahtic approach has blossomed into an accepted field of social policy 
anal) sis with numerous successes including. 

• Urban Dynamics, a studv^ of the policy impacts of urban housing developments, 

• Limits to Growth, a studv of earlli's ability to sustain mankind under current environmental trends, 

• The National Economic ModeL a studv of business cycles in the United States, and 

• numerous business and social process models. 

These models, as well as previously mentioned models (1.1.1 and 1.1.2). are particularly useful in their abilitv to 
show why a seemingly useful organbational policy fails to produce the results expected from policy managers. 

For example. Analog Dev ices Inc (ADI) of Norwood. Massachusetts, a producer of higli-end integrated 
circuits successfully applied a Quality^ Improvement Program to their production process.^^ Tlie goal of the program 
was the improvement of product quality (reduction of errors), on-time delivery and reduction of production cy cle 


Jay W. Forrester, "The Beginning of System Dynamics", banquet talk at the international meeting of the System 
Dynamics Society, Stuttgart, Geniiany, July 13, 1989. 

Dr. Louis Alfeld, "The System Dynamics Modeling Methodology", Decision Dviiamics Inc, 1994, 
wwvv.decisiondvmamics.com. 

Robert Kaplan. "Analog Devices: The Half-Life System", Harvard Business School case studv, 1990. 
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time. Tlie improvement process found great success on the production floor within a ver\^ limited time (2 years.) 
However, when management attempted to apply their program to product development, it not only failed, it began 
negativ ely impacting the production cycle. A system dvTiamics model was generated and showed managers that 
failure to adjust the improvement program goals relative to the time scales of production versus development had 
generated the failure. Human intuition (if the improvement was effective in production it should be effective in 
development) failed to understand the d\ naniics of how the improv ement process disseminated through the 
organization and how' the various sectors of the organization are inter-related. System dynamics is effective at 
showing these process factors. 

1.2.3 Modeling Approach and Structure 

Tlie procedure for developing and anah’zing a system dynamics model is well stated by Randers.^^ The 
procedure is applied in four stages; 

1. Conceptualization 

2. Formulation 

3. Testing 

4. Implementation 

Witli respect to the naval design model, stage 1 is discussed in Chapters 1-4 and stage 2 in Chapter 5. Stage 3 is 
presented for a few select cases in Chapter 6 and stage 4 will be considered for future application in Chapter 7. 

Specifically, stage 1 involves the consideration of the problem to be studied (as stated in Chapter 1.1.1 page 
13), temporal bcliavior of important vanables in the problem (such as presented in Figure 1 Combatant Cycle Time 
Trends) and hypothesis of casual mechanisms within the studied process. To this end, the naval design model 
examines factors exiemal to the design process for a single surface combatant program (budgeting, performance 
changes, design resource availability within the context all naval design projects.) However, these factors are not 
explicitly modeled, rather assumed as exogenous inputs to the model. Endogenous model elements include physical 
design task flows, design organization relativ e to design resources, design decision processes and cost constraints to 
the design process. 

Stage 2 presents a specific model for a surface combatant design program (DDG-51 program.) The model 
builds on elements of previously dev eloped, sy stem dy namics models. Tliis approach enhances mathematical 
accuracy' of the model as well as validity relativ e to accepted modeling practices. However, the selected model 
elements are tailored to the behav ior modes expressed in stage 1. In particular, the model reflects the impact of 
naval design task inter-relationslups based on the design spiral (Chapter 4.) 

Stage 3 demonstrates the model calibrated to the DDG-51 Program (August 1978 through September 1991.^^) 
Given replication of baseline behavior by the model, several “What if’ scenarios are proposed: 


Jorgen Randers, “Guidelines for Model Conceptualkation Elements of Svstem Dynamics Method MIT Press, 
Cambridge, MA, 1980. 

Ship Design Group, Ship Design Project Histories Volume II 1980-1989 . Nav al Sea Systems Command May 
1986, pages 2-8. 
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1. Application of 3-D Product Models and Simulation Based Design, and 

2. Application of Integrated Product Teams and Concurrent Engineering. 

The results of these scenarios provide relative assessment of the improvement processes for consideration agamst 
accepted ‘‘mental models ’ of how those processes should effect the process. 

Finally, stage 4 discusses the future uses of the model as a tool specific to surface combatant programs (like 
the DD-21 program) when continuously calibrated and adjusted as process improvement results are available or 
alternative “what-if'’s are asked. As such, the model is proposed for use as a “management flight simulator’ in 
naval design programs. The model may further be incorporated into the structure of larger models addressing 
complete life-cycle (design through production through operations and support) and cross-programmatic (budget 
allocation and project phasing) issues. Finally, the model is considered for its potential role as a piece of a larger 
‘'cost-schedule-performance’' model 
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2 Design Process External Influences 


When first analrang the problem of cycle time growth, it is necessaiy^ to understand the external influences 
that constrain and drive the design process. The externalities generally consist of strategic variables and decisions 
such as total force structure and capability (order of battle), national defense budget and budgetary allocations, threat 
capabilities and capability differentials (gap between our force and an enemy.) These externalities play a critical 
factor in cycle time growth. As such, the only true method to reverse cycle time trends is to understand and control 
the forces of the externalities. However, changes to the overall acquisition and force structure are not within the 
scope of this thesis. Rather, the goal is to establish a model representative of internal process forces, such that 
improvements proposed to the internal structure can be assessed. Therefore, we will examine the exiemal influences 
to recognize their impact on the design process as exogenous inputs, leaving external analysis and decisions to 
alternate forums. By understanding Uie effect of exlemal forces, the internal process can be designed to minimize 
their impact. 

The follow ing influence diagram. Figure 10. shows a number of the important reinforcing and balance loops 
which ultimately effect the design process. The loops represent those cause and effect mechanisms that act in 
concert with and as feedback to many of the behaviors apparent in the process of budgeting, setting requirements 
and managing schedules. Tlie loops are influenced by a combination of obser\ ed temporal variations (behavior 
modes), physical responses (decision policies and mechanisms) and structures required to close feedback processes. 
In particular, note the mechanisms influencing "Design and Acquisition Rate" (instantaneous design cycle time.) 

The rate is impacted by resource availability, acceptable risk levels and design complexit>\ The v ariables showii 
aggregate many v ariables (design and acquisition rate represents tlie average rate for all current design projects.) 

The diagram also establishes boundaries (primarily encompassing naval sliips) that could easily be expanded or 
contracted to capture additional trends. 

These dynamics represent a series of dynamics specifically noted by nav al process experts during interviews 
held August 24-28, 1997, November 12-14 and 19, 1997 and December 8-11, 1997. The interv iews included 
gov emment design managers and engineers (NAVSEA and Nav al Surface Warfare Center Cardcrock Div ision), 
commercial design support and shipbuilders (John J McMullen and Associates, Techmatics Inc, SYNTEK Inc.. 
Newport News Shipbuilding, and Bath Iron Works) and academia (MIT and Sloan School of Management.) A 
complete listing of personnel interviewed can be found in Chapter 8.2. 

The dv namics are examined indiv idually to clarify their inclusion in the totality of external process 
influences. 
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Covered Naval Conlmitments 
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2.1 Reciprocity and Proliferation...the Need for Naval Capabilities Evolution 

In his 1996 thesis on the naval ship production process \ Tim McCue introduced the concept of the "Arms 
Race Dynamic.” This (i>Tiamic is shown in Figure 11. There are two dynamic loops at work in this process: the 
Proliferation Dynamic and the Reciprocity Dynamic. The Proliferation D>namic is well understood by mililan' 
strategists and is a source of debate with respect to international control of weapons and capabilities (particularly 
weapons of mass destruction and “smart weapons”. The Proliferation Dynamic is a “snowballing dynamic” and 
may be characterized as follows: 

1. As new weapons and doctrines are introduced into serv ice by US forces, these capabilities will diffuse 
(or proliferate) over time such that tlu-eat forces possess reciprocal capabilities (either equiv alent or 
negating) 

2. As proliferation carries on, US intelligence metliods will characterize the threat based on actual and 
consequentially, perceived capability^ of the threat force 

3. The perceiv ed threat will be weighed against US capabihtics resulting in a US adv antage (or deficiency) 

4. As proliferation continues, the US adv antage will decline and pressures to enliance US capabilities will 
begin to increase 

5. As pressures to enhance capabilities increase, the US forces will improv e 

6 Force improvements will be noted by the threat force that will in turn seek to gain the same enlianced 
capability' or a negating capability...and so on. 

The Proliferation Dvnamic has many other details not noted here (such as cost of new capabilities, tecluiological 
complexity and political landscape) which have significant impact on the rate of proliferation. However, time has 
shown tliat proliferation rate may be moderated but as long as inequalities exist diffusion will occur. 


^ Timothy P McCue, “The EHnamics of Naval Shipbuilding-a Systems Approach”, Department of (3cean 
Engineering Thesis, Massachusetts Institute of Technology, June 1997. 

William S. Cohen. Report of the (Quadrennial Defense Re\ievv, United State Department of Defense, May 1997. 
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Figure 11 Arms Race Dynamic 

In order to balance the threat of Proliferation, US forces must follow with Reciprocih Tlie ReciproeiK 
Dynamic is characterized as follows; 

1. US forces start at a gi\di force level (US Naval Order of Battle) 

2. The US force has an inherent capability achantage (or deficit) when compared to potential threat levels 

3. Pressures to increase US capability (typically political) increase as the US advantage is decreased 

4. Tlie source of new’ miUtaiv’ ad\’antages may originate from new’ capabilities (new ships, weapons, etc.) or 
changes to enliancc doctrine to emplov’ current forces 

5. Capabilities increase the US ach antage until pressure to improve is nullified. 

As with Proliferation, Reciprocity can be further described b\’ additional \'ariables such as current political climate, 
defense costs and the state of the US economy, or percei\’ed level of international stability’. Howc\’cr, as long as the 
US continues to choose a role as a leader in w orld affairs, militaiv’ strength (advantage) will likely be the doctnne of 
choice. 

Two detailed expansions of tlic Arms Race Dy namic are also demonstrated. First, the new construction 
dynamic demonstrates tliat one metliod of increasing capability' is to develop new’ weapon and ship s}'stems The 
construction of new^ designs (increased with increasing design rates, measured as new designs completed o\ er time) 
results in the increased order of battle. ..completing the reciprocity’ balancing force. A second dvnamic expansion is 
tlie impact of technology from proliferation. As proliferation of ach anced defense technologies occurs, the 
complexity’ of new designs required to counter those teclinologies increase. As complexity’ is increased the design 
rate slow s (more time is required to gain equivalent leaps in perfonnance ad\ antage), new constructions slows and 


38 







the order of battle decreases... ultimately the abilit}^ to maintam capabilit\' advantage will be lost to the balancing 
force of technological complexity. 

The *'Arms Race Dy namic'’ lies at the heart of the Nav al Design Process as the primaiy' influence effecting 
the need for new designs, the need to support operating forces, the mcreasing complexity of newer designs and the 
acceptable levels of risk relative to cost, performance and cycle time. Consider Figure 12. Correlated against the 
trends shown in Figure 1 and Table 8, US warships have been dedicating larger fractions of procurement costs to 
combat s> stems in response to ever growing threats, while the combat sy stems themselv es are achieving 
exTX)nentially decaying improvements in capabihty. and the net development cycle is slowing to accommodate 
assessment of tlie threat and dev elopment of systems capable of countering those threats. As long as new threats are 
generated and the US chooses to counter those threats, the cy cle will continue to generate the need for a non-zero 
design and acquisition rate. 



Figure 12 Naval Surface Combatant AAW Reaction Time Trends^^ 


2.2 “Order of Battle” Dynamics...Maintaining Force Levels 


Tliis second dynamic both drives the need for new' designs and counters the ability to produce new designs. 
Shown in Figure 13, the "Order of Battle” dy namic demonstrates the mechanisms by wiiicli ev en a static threat 
ultimately requires creation of new designs. First, consider the “Grav ing ’ Fleet Dy namic. For a static capability' 
lev el, time eventually degrades the capability. For Example: 


Prof. Charles Calvano, Total Ship Sv stems Engineering, http://vveb.npgs.navT.niil 
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1 The current US aircraft carrier capability is known (Figure 14). 

2. The desire for the US to engage specific commitments (Persian Gulf, Adriatic or South Chma Sea) 
results in carriers being assigned to the regions. 

3. As commitments increase for the fixed number of carriers, the average aging process for those committed 
carriers increases. 

4. As carriers age, the useful life is expended imtil decommissioning. This increases the average age of the 
total fleet but at the cost of reducing tlie overall order of battle. 

5. Finally, as the age of ships increases and fewer are available due to decommissioning or increased 
maintenance time for older vessels, the order of battle decreases... 

These balancing forces (meeting commitments ultimately means not meeting commitments) are reversed by the 
counter-balance of the reciprocity dynamic. This is one of the factors currently driving the CVX program to replace 
aging carriers (Figure 14.) 

An additional chnamic proceeds from the "Gra\ing' Fleet chnamic... Fleet Demand EHnamic. By this 
dynamic. 

1. Increased fleet age (as a result of time and increasing commitments) generates pressure from operating 
forces to devote funds to maintenance and support of operating ships 

2. The pressure increases as the total force lc\ el increases and limited funds are allocated across a larger 
inventory of operating vessels 

3. The pressure translates as an increased demand on engineering resources (commercial and nav al) to be 
dedicated to fleet support vice development activ ities, 

4. The pressure forces increased operation and support (O&S) expenditures within the fixed constraint of 
total available defense budget, 

5 The increase of fleet support resources and O&S expenditures reduces available funding for development 
projects, 

6. Tlie increase of fleet support resources and O&S expenditures improves the Order of Battle vvliich 
increases naval commitments covered, 

7. Ultimately increasing the average age of v essels... 

The result is reinforcing behavior.. .aging ships demand resources to maintain force levels which demand more 
resources and so on. This behavior fueled much of the deficit spending required to supported the defense build-up 
of the 1980's. 

A third behav ior has been especially apparent in the last few years, a trend to pay for newer capabilities with 
the decommissioning of older vessels... "Pay with Past" dynamic. Consider the follow ing trends: 

1 For a giv en force lev el (order of battle) decommissionings mav^ be considered to reduce O&S 
e.xpenditures, 

2. As more slups are decommissioned O&S expenditures decrease which increases funds a\ ailable for 
procurement (R&D and SCN), 
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3. Allocations of procurement funds to industr\' and government resources result in a pool of Engmeenng 
and Acquisition Resources, 

4. As this pool increases the design rate (new designs produced over time) increases and new designs and 
acquisitions result, 

5. Ultimately increasing the order of battle in the fonii of new ships and capabilities. 

Tins behavior is balancing... decreasing order of battle w ith decommissioning w ill increase order of battle w ith new 
construction. During the down-sizing of the 1990’s, many new construction programs and upgrades to operating 
units w ere funded with tlie decommissioning of older vessels. However, tlie majority of the recovered funds were 
lost to a shrinking defense budget and increases in O&S funds required for support of US commitments (Somalia, 
Haiti, Bosnia, Persian Gulf, etc.) 

A final beha\ior of note is the Industrial Demand Dynamic. Proposed by Dr Harv ey Sepulski^*^ 
(Massachusetts Institute of Technolog>), this dvTiamic has received significant focus from the defense industrv' in 
recent years: 

1. If allocations for contracted resources decreases (due to decreasing defense budget funds), there is 
increased pressure from industrv' (on Congress and on government acquisition authorities) to privatize 
government operations 

2. As pressure increases, greater portions of funds are given to industrv', 

3. The increased allocation to industrv' decreases pressure for privatization... 

The result is a balancing force w ithin the defense industrv’ with respect to available defense funds. Note that 
increasing privatization must be coupled with decreased in-house resources for a fixed budget. 

Tlie dynamics of these Order of Battle factors impacts the design rate tlirough fund allocations (giving and 
taking from development programs) and as factors requiring the introduction of new forces to replace older ships. 
Many of these dynamics are currently being examined by industrv^ as potential areas for privatization of fleet support 
expenditures. ^ 


Presentation to Ocean Systems Special Project course at Massachusetts Institute of Teclmologv, Spnng 1997. 
Prof Jim Hines, Applications of System Dvmamics course project supporting the Boeing Corporatioa Sloan 
School of Management, Cambridge, MA^ Spring 1998. 
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Figure 14 Timeline for US Aircraft Carrier Development and Decommissioning 


2.3 Design & Acquisition Rate Influences 

The cycles of the Arms Race and Order of Battle are shown to demonstrate tlieir influence over the topic of 
primaiy concern: Design Rate. In particular, it is important is understand how these d>narmcs control design rate 
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(and thus, design cycle time) tlirough the functional input of performance and cost. Figure 15 show s an expanded 
view of these inputs. It has already' been shown implicitly that design rate is impacted by changes taking place in 
cost and performance (Chapters 1.1.2 and 1.1.3) as well as by the dynamics of performance requirements (Chapter 
2.1) and cost constraints (Chapter 2.2.) Design rate is also explicitly impacted by cost and performance constraints. 
Consider the case of the DDG-51 program. During the preliminary' and contract design process, design managers 
applied an approach of a ‘‘closed loop feedback control process of establishing budgets, rex iewing the design for 
conformance to the budgets, and making decisions to change the design (within performance constraints) where 
design features exceeded the established budget.”^^ Figure 16 demonstrates this form of “dynamic cost control*’ 
with an exponential increase in cost from an initial baseline througli the end of the Feasibility' Design Phase 
followed by a very rapid oscillation beginrung in May 1983 to stabilize the cost ($700M follow-ship acquisition cost 
in FY83$.) Coincidentally, May 1983 represented the official start of the Contract Design Pliase.. .a period during 
w hich cost becomes very' apparent and engineering manpower rapidly' ramps-upward to facilitate increasing design 
tasks^^. The result of this process w as a lengthening of the design schedule by se\'eral months to accommodate the 
additional analysis and review. 



Figure 15 Design Rate Dynamic Inputs 


Hope and Stortz, "Warships and Cost Constraints*’, Na\al Engineers Journal, March 1986. page 43. 

Ship Design Group, Ship Desigui Project Histories Volume II 1980-1989 , Naval Sea Sy stems Command, May’ 
1986, pages 2-8. 

Hope and Stortz. "Warships and Cost Constraints". Naval Engineers Journal, March 1986, page 46. 
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Contract Design-Cost Trends 


O 

O 


(U 

E 

E 

3 

U 

o 


o 

% 

E 



■o 

c 

01 


a 

!c 

CO 


Date of Analysis 


Figure 16 DDG-51 Contract Design Procurement Cost Estimate Trend” 
Tliese inputs and cycle time dynamics are explained by the following influences: 


1 

7 


Increases in design complexity (performance required) lengthen tlie design process (slow the design rate) 
Decreases in design funds and engineering resources lengthen the design process as acquisition 
authonties become risk adv erse (hesitant to commit funds) and basic resources become diluted among 
design projects 

3. As perceiv ed tlircats from proliferation and decreasing US advantage become apparent, pressures to 
increase design rate (shorten cvxle time) come from reduced schedules and willingness to accept greater 
design-performance risk 

4 Finally, as the volume of designs in progress increases, the rate naturally adjusts (balancing) as schedules 
for immature designs are relaxed to focus resources on designs in the later stages of completion. 

These influences represent the input variables that must be considered for inclusion in a design process model. 
Hovvev er, these vanables are exiemal to a specific design project. Althougli a design manager must consider issues 
such as increasing performance requirements or reduced funding from the defense budget, he has little control over 
budget allocations to other programs or tlie cancellation of a teclmolog>' pipeline bv' a sister service in the DoD. As 
such, these variables are included as exogenous inputs to the model. The model provides a means to change the 
assumptions of the inputs, thus allow ing the gaming of potential scenarios driven by those influences. 


Vernon E. Stortz, ‘‘DDG-51 Design-Cost Trend Log”, unpublished, Naval Surface Warfare Center Carderock 
Division, Bethesda, MD, August 1984. 
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Design Process Dynamics 


3.1 Systems Engineering and Nava! Ship Design 

The naval ship design process is the process of establishing a militar\' need, defining this need in terms of 
militar>' requirements and constraints, performing a set of design tasks to develop a solution, validating the solution 
versus the requirements, and translating the solution into a form usable for production and ship support. Figure 17 
demonstrates this concept and it’s iterative elements. These steps are repealed at each stage of the design process, 
from concept to production design, ^ith the detail of the tasks increasing concurrently with the maturity of the 
design. 


Design Elaboration & 

Design Iteration Error Correction 



Iterathe Trade-Offs 


Figure 17 Systems Engineering Process^® 

The dominant accumulations and flo\\ s in this generic process are as follows: 

1. Input requirements generation (such as tlircat analysis and Mission Need Statement (MNS) generation) 
with tasks for analysis of mission needs 

2. Functional analysis tasks (such as Industrial Base Assessment and Analysis of Alternatives) that establish 
reasonable system options 

3. Synthesis tasks (such as hullfonn design or combat s\ stems integration) that define and optimize the 
system 

4. Evaluation and decision (such as ship vulnerability modeling or milestone approvals) vvitli tasks to 
examine and approve or disapprove completed design tasks, and 

5. Description of System Elements (such as Contract Specifications or Construction Drawings) to translate 
system requirements into component and production specifications 

Several important feedback flows are apparent in the process. Iterations may result from physical design 
balance, design errors, risk mitigation, scope change, and modification of input requirements. Physical convergence 
is centered on design svntliesis. 

Synthesis in naval ship design is modeled in the design spiral. The dynamics of spiral concurrence and 
information transfer are a unique property of nav al sliip design. A more detailed discussion is presented in Cliapter 
4 


Kockler, Withers, Poodiack and Giemian, Systems Engineering Management Guide , Defense Systems 
Management College, Januarv' 1990, page 1-3 and 5-2. 
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An important source of feedback is error disco\ er}' and correction. Errors themselves may be generated at 
any stage of the process. Early in the process, errors occur when objectives and requirements are erroneously or 
imperfectly specified. The mechanisms described m Chapter 1.1.2 are designed to mitigate the probabilit\' of errors 
in these stages. During later stages, errors may be caused by communication disruptions (design hand-offs), 
misinterpretation of specifications, inaccuracies or singularities in design algorithms (computational inaccuracies, 
design modeling assumptions or discontinuities in design variables), and human factors.^^ 

Error detection and management topically occurs during specific Quality Assurance (QA) stages. QA is 
defined as “a set of activities performed in conjunction w ith a (project) to guarantee the product meets the specified 
standards... these activities reduce doubts and risks about the performance of the product in the target 
environment.'’^^ As errors are detected, the deficient tasks are relumed to an appropriate stage for correction. As 
demonstrated in Figure 17, error correction t}pically returns to s>Tithesis. For this reason, it is possible that the 
correction stage may not be the source of the error, thus providing the potential for future error generation. Note 
that this is a reason for the emergence of Total Quality Leadership (TQL) within the Navy as a method to anah7;e 
errors and their causes. 

A final source of iteration is the modification of requirements and functional analysis products resulting from 
evaluated designs. These modifications can include design changes (failure of the current design to meet 
requirements) or changing requirements themselves (necessitated by cost or performance trade-offs.) Additionally, 
as the project proceeds through time, the requirements themselves change in response to changing external needs 
The result is scope growth. Such growth has a negative dvnamic impact: reinforcing work to be done and often 
dominating the balancing effects of iteration Consider a study of scope change impacts conducted by the 
Construction Industry^ Institute.^^ The stud\' e.xamined tlie change in productivity resulting from increasing fractions 
of change. The study compiled data for 104 projects from 35 different companies. The results showed that 
engineering productivity (measured as a ratio of earned work-hours to expended w ork-hours) decreased linearly at a 
rate of 5% productivity for 10% increase in design changes. Tlie effect translated into similar productivity decreases 
for construction. 

3.2 Acquisition Process... Points of View 

To facilitate the management of the above systems engineering approach, the Department of Defense has 
formalized the stages and processes. Tlie foniial process is referred to as the acquisition process. Figure 18 show s 
the major phases and milestones of the acquisition process. The acquisition process includes many steps that extend 
both before and following s\ stems engineering. For instance, pre-Milestone 0 includes not only requirement 
definition (Determination of Mission Need) but also the examination of available technologies (Science and 
Technolog>0 that would be required to support Functional Analysis (Concept Exploration.) The examination of 


Abdel-Hamid & Madnick, Software Project Dynamics: an Integrated Approach , Prentice Hall, New Jersey, page 
95-96 

Ibid., page 101. 

Construction Industiy^ Institute, “(5uantitati\ e Effects of Project Change ', ClI Source Document, March 1990. 
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technologies may itself be a systems engineering exercise as managed research solutions must be constantly 
assessed for the range of applications to which those technologies are being developed. The acquisition process also 
extends beyond production level engineering at Phase II (Engineering & Manufacturing Development.) 

Specifically, the acquisition process manages tlie complete production (Phase III) and support (Operational Support 
and Demilitarization & Disposal) for tlie fielded s> stem. As such, tlie acquisition process encompasses not only 
system dev elopment, but the entire life cycle of the system. 



Figure 18 Acquisition Milestones and Phases^^ 

Perhaps the largest difficulty in understanding the na\ al ship design process (or any defense design process) 
is the large field of views that process observ ers may take. Consider Figure 19 below This diagram shows the 
range of management considerations (shown as timelines) contained within the DD-21 acquisition process. Within 
this program, participants may take widely differing process views based on tlieir own requirements to focus or 
optimize process efforts relativ e to a particular trade-off. For instance, the primarv' engineering focus is the 
sequence of design reviews (ASR through FCA) necessary to define conceptual baselines, svstem definition and 
design producibilitv. The engineering view seeks to provide the best physical system (performance) as a response to 
the giv en requirements. Altemativ ely, budgetarv' and fiscal managers are focused on milestone relationships, since 
the satisfaction of specific milestones translate directly into funding increases required to support continuing levels 
of design effort. Additionally, budgetarv’ managers optimize the use of funds against budgetarv’ and fiscal nsk. 
Industn^ and acquisition managers must concentrate on the vanous contracting phases (in addition to the other 
process phases) in order to maximize allocation of intermediate program funds (such as support contracts) while 
remaining poised to compete for the final contract award. Additionally, industry managers seek to optimize 
producibilitv' relative to their own production processes. Through optimization of cost and schedule, industrv seeks 
to gain a competitive advantage for contract award. 

Each of these points of view are seeking to dev elop a systems level optimization of the final design. 

However, the optimization is relative to the area of concern to the particular component managers. This is not to say 
that component managers ignore total system optimization. They are quite aware of the potential impacts resulting 
from changes to a particular sv stem element. Tliey are especially sensitive to the impacts of changing inputs 


Defense Acquisition Dcskbook Joint Program Office, "'Defense Acquisition Deskbook, Version 2.2.87”, WriglU- 
Patterson Airforce Base, Da>1on. OH, December 15, 1997. 
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resulting from s> stem interdependencies. Ev er changing requirements of the military and resulting changes in 
optimization priorities dictate that no one element dominates through the entire design process. As such, component 
managers must constantly strive to champion their s\ stem element to achieve necessaiy^ consideration in the final 
design. The dy namic impacts of these changes have already^ been demonstrated (see discussions of Table 2 and 
Figure 16). These competing relationships and task interdependencies are examined in detail in Chapter 4. The 
immediate results of compartmentalized and competing demands are obvious: each component manager pushes 
fonvard with necessary' tasking despite changing priorities and no one component view delivers total system 
optimization. 

In this environment of competing sy stem interests, it is the task of the program manager to assess the needs of 
the dev eloping system, determine the range of available resources, and assign priorities to optimization goals. 

Within this context, the program manager works to the following principles and objectives’.^^ 

• Ensure effective design and price competition. 

• Improve sy stem readiness and sustainabihty' 

• Increase program stability through effectiv e long-range planning, use of ev olutionary' alternatives, 
realistic budgeting and funding of programs for the total life cy cle, and planning to achiev e economical 
production rates 

• Delegate authority’ to the lowest lev els of the serv ice that can prov ide a comprehensiv e rev iew of the 
program. 

• Achieve a cost-effective balance between acquisition costs, ownership costs, and sy stem effectiveness in 
terms of the missions to be performed 

Giv en this range of responsibilities and management decisions, the program managers tasking in the design process 
naturally extends to all facets of the project. Tins fact is explored more fully in Chapter 4.4. 


Kockler, Withers, Poodiack and Gierman, Systems Engineering Management Guide , Defense Systems 
Management College, January' 1990, page 2-1. 
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3.3 Operational Process View 


3.3.1 Design Phases 

Increasingly, naval ship design is becoming a subset of total ship s> stems engineering (TSSE). Ship concept 
exploration and combat s\stem development must begin well in acK ance of the actual ship design process. As such, 
the superset of system design spaces will encompass many layers of system optimization and process views. The 
global exdeniahties described m chapter 2 represent a strategic view of the design process. The s>'stem design and 
acquisition processes described m sections 3.1 and 3.2 represent macro \iews of the design process. The remaining 
views are operational views. The operational views provide the exacting structure that is necessaiy^ to capture the 
dvTiamics of design process change relative to process improvements. Specifically, the operational views are 
represented by the notions of Design Phases and the Design Spiral. The design spiral is examined in detail in 
chapter 4. This section examines the four phases of naval ship design: Concept Design, Preliminary' Design, 
Contract Design and Detail Design. 

Concept Design is the phase during which the solution space is examined to identify potential cost-effective 
solutions to the stated requirements. In the acquisition process, this stage is represented by all activities prior to 
Milestone I. The requirements are presented by the ongoing Requirements Definition subphase during which 
warfighters recognize an operational need and translate that need into requirements for engineering and acquisition. 
The overall ship sv stem is emphasized w ith specification of components limited to a few significant sv stem driv ers, 
such as w eapons or propulsion plants. The products of the Concept Design are a set of defined requirements and a 
design space of achievable solutions to requirements. 

Note that the iterative properties of the macro view of systems engineering are present both externally and 
internally. Externally, the concept design phase represents the first stages (requirements and functional analysis) of 
systems engineering. Internally, concept design contains explicit elements of all sy stem engineering 
steps... requirements, sy nthesis, approval and description of sy stem elements for the next phase. These intemal and 
external characteristics are common to all design phases. 

Preliminary Design is that phase during which one or a few desired concepts are refined by analysis and 
integration of specified components to confinn acceptable system capabilities. In tlie acquisition process, 
preliminarv' design is represented by Phase II (or more often Phase II A.) Tlie purpose of preliminaiy' design is to 
focus on ov erall system effectiveness and assurance that specified sy stems can be technicalh and economically 
supported b>' the ship design. In particular, engineers and managers concentrate on loigh risk elements of the design. 
Such higli risk elements may include: industrial base support, combat systems integration, hullfomi performance 
characteristics, life cycle cost, or optimization of marine sv stems efficiency. As a result of in depth analysis of 
specific systems, the products of preliminarv' design contain increasing degrees of component specification, but still 
focus primarily on sy stem level definitions. 

Contract Design is the specification of design attributes necessarv’ to reduce risk for the Na\y during the 
av\'ard and constmetion of the selected design. Tlic contract design process is still functional!) oriented. However. 
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increasing numbers of components are specified in detail. Specifically, design attnbutes are specified by contract 
specifications to constrain design performance and reduce risk. These constraints may in turn constrain costs, 
possibly to the detriment of the design process. Like preliminary’ design, contract design is part of phase II of the 
acquisition process (or phase IIB). 

It is important to note that ilie traditional design responsibility up to and including contract design has resided 
with the Na\y. As discussed in Chapter 1.1.1, NAVSEA would conduct the bulk of engineering analysis with 
contractors providing support services, but providing little influence over the direction of the design. However, this 
trend is changing. Recall the transition points show n in Figure 5. Under the old (DDG-51 and prior) approaches to 
surface combatant design, the end of contract design represented tlie transition point of the design from the 
govermnent to the shipbuilder. Under this approach, the shipbuilder received very specific contract and mihtaiy' 
specifications directing tlie materials, components, and even production methods for the design. As shown 
pre\1ously, the result of tliis inflexibility’ was delays due to late GFI/GFE/GFM, schedule and cost growth in excess 
of marginal scope changes, and increasing ship production costs. To counter these effects, current programs (DD- 
21) are pursuing earlier transition of design responsibility’. Bv' specifying performance requirements, shipbuilders 
are free to pursue design alternatives optimized to their production capabilities. Although the contractors will 
assume early design responsibility , there must still be a detailed contract specification prior to shipbuilding contract 
award Tliis contract specification is necessary' to define the product for which ship construction funds (SCN) are 
allocated as well as commit the shipbuilder to legally binding design perfonnance (i.e. a performance specification 
will not hold the weiglit of a contract specification in a court of law.) 

Detail Design is the phase during which s>’stem descriptions are translated into the instructions required to 
support constniction, operation and support of a finished ship. Williin Detailed Design are four sub-phases required 
to support contractual and production requirements During Functional Design, the shipbuilder specifies ship 
system components and verifies that the selected systems will satisfy’ performance requirements. Functional Design 
provides the linkage betw een desired s> stem configuration and specified performance predicted b}’ contract design 
and realized s>'stem performance available from a producible design. Functional Design is sometimes associated 
with contract design by the notion of Contract Definitization. Tliis is potentially significant when multiple lead 
ship contractors are bidding for a project. During such instances, functional design represents a further 
demonstration of design quality’ and cost for differentiation of contract bids. Howev er, experience has shown that 
lead ship design aw ards typically proceed in advance of contract design end As such, functional design becomes 
the initiation of detailed design concurrent with completion of contract design. Transitional Design takes the ship 
system description and incorporates it into a process-based description Long lead items (propulsion engines, 
propellers, combat system components, etc) and material requirements lists (MRL's) are incorporated into the 
shipbuilder logistics sv^stem. Zk)nal Design develops components into drawings consistent with the work 
breakdown structure required for ship construction. After this subphase, tlie Navy will own and, williin contractual 
limits, distribute the design to all ship builders w ho hav e successfully bid for a constaiction contract. For tliis 
reason, these first three sub-phases of detailed design (Functional, Transitional and Zonal Design) are often referred 
to as Lead Ship Design. For a lead ship design effort, tlie products are intended to support all ship builders and 
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component vendors participating in the ship construction program. However, the actual process will often result in 
detailed design attributes that support the construction of the ship in the Lead Ship Yard As such, participating 
yards will necessarily modify the Lead Ship Design to be compatible with their production processes. The result is 
the ver>' notable difference between ships of a common class built in competing ship yards. The final stage of 
design. Production Design or Manufacturing Engineering, begins as soon as engineering and production 
resoiu'ces, as well as zonal design products, permit initiation. Production Design extracts the final drawings (lofting) 
and manufacturing instructions required to produce the ship. This phase also provides the interface with the 
construction site to resolve design conflicts encountered during construction. 

3.3.2 Scope Change Implementation and Detailed Design 

Detailed Design is influenced by dynamics encountered due to “Internal Change” (producibility 
accommodations, error and interference) and “External Change” (engineering change proposals and GFIATI 
changes).^^ Internal Change represents those factors over which the design organization has some degree of control. 
Internal changes include Engineering Assistance Requests (EARs) or producibility enhancements. The dynarmcs of 
internal changes require assessment of the improvement versus detrimental impacts. For instance, error rates cai be 
reduced with increased QA. However, increased QA naturally delays the schedule and commits valuable resources 
away from tasking. Tims, a trade-off must be determined internal to the project. External Changes are those factors 
over which the organization has little control. External changes are either Nav>^ Engineering Change Proposals 
(ECPs) or vendor changes. For instance, as requirements change, the design must change (despite the negath e 
system impacts of change) otherwise the design fails to meet the perceived need. 

All clianges are anal>'zed for schedule, material and production impact. The level of analysis varies 
depending on the complexity of the change. A simple interference identified by an EAR will be anah^ed by the 
production design representative on the waterfront and processed in accordance w ith standard procedures. A 
complex ECP is anal\7:ed by system and functional engineering, design, material engineering and planning 
specialists. If the proposed change is considered necessar\\ an action plan is developed which integrates the change 
into design and construction process. 

Design changes originating during the construction process are pro\’ided to manufacturing as interim products 
known as “Revision Notices” (RNs). Tlirough a “lock-step” process, fabrication and installation drawings extracted 
from the CAD models are continually maintained to reflect the current design baseline via RNs. It is essential that 
configuration control of the models and drawings be maintained while new design changes are introduced. Re\ised 
drawings are reproduced at regular intervals to support the next follow on hull that take into account the multiple 
design changes created during the construction of the pre\ious hull. During these maintenance cycles, all 
outstanding change paper is accounted for and a “clean drawing” is produced. Similar to the lock-step process, parts 
lists are continually updated as changes are identified. External Change and Internal Change are specific 
representations of scope growth of a project. 

C. R. Lloyd, ‘ Design Process for the AEGIS Destroyer Program”, Presentation, Bath Iron Works D87 Class 
Design Office. November 18, 1997, page 6. 
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4 Design Spiral and Task Dynamics 


4.1 ‘The Design Spiral” 

The design of a ship is not the act of designing specific equipment.. .rather; it is the integration of systems and 
equipment to optimize cost and effectiveness.^^ Such activity is inherently multi-disciplinary (‘'no single person can 
be expert in all these areas"^^) and highly iterative. However, this is not to say that the process is without 
recognizable structure and organization. To the contrary, the naval ship design process must follow very specific 
steps and satisfy fundamental physical laws in order to achieve a balanced design. These balanced properties range 
from the most basic (hydrostatic balance, resistance-to-powering balance, stnictm-al stress-to-integrify’ balance, etc) 
to those demanded for increased effectiveness and decreased cost (passive-vs. active-defense trade-offs and design 
optimization vs. producible design.) 

Tlie most widely accepted methodolog>’ used to balance design requirements to ship components is the design 
spiral. The design spiral describes the process that compartmentalizes the design disciplines and regiments the 
engineering steps necessary for a balanced design. Figure 20, shows a fypical example of such a spiral. (Note that 
the concept of the design spiral is attributed to Professor J.H, Evans of MIT and was first introduced in the Naval 
Engineers Journal November 1959.) 

Fundamentally, the spiral is a ship-system algorithm that combines physical relationships with trade-off 
options. The spiral is characterized by a sequence of specific tasks that incorporate initial design requirements, 
synthesize these requirements into a set of design characteristics, assess the design characteristics against the 
requirements and against one another, and iterate as necessary to achieve convergence of the \ alues. The design 
spiral relies on three important features to enable analysis and convergence. First, tlie design space from which all 
potential design characteristics may be chosen is not infimte. Rather, the design translate into a specific design 
space (known as design lanes.) Tliese design lanes enable engineers to assume a set of initial ship characteristics 
and, thus, proceed with the design analysis. Secondly, the spiral generates specific design characteristics and 
modifies the values as nccessarv^ to meet requirements. As such, the design assumptions at the beginning of a spiral 
differs somew hat from tliose at the end of an iteration. The spiral process incorporates the new design values into 
each successive iteration until the values converge to a balanced design. Design balance indicates the defined ship 
characteristics are physically stable while satisfying design requirements. It is important to note that a balanced 
design may not necessarily represent the optimal design.^^ Finally, as iterations proceed and convergence is 
achieved, the process of synthesis and analysis seeks greater and greater levels of detail. For instance, imtial 
structural analysis incorporates simple beam theory; ship section modulus and accepted design practices. Later 

Gale and Scott, "Early Stage Ship Design Seminar'; The Sociefy^ of Naval Architects and Marine Engineers, 
October 1995. 

Tibbitts and Keane. "Making Design Everybody's Job'’, Naval Engineers Journal. May 1995, page286. 

Allan Andrew, “Multi-Attribute Decision Making Analysis with Evolutionary^ Programming Applied to Large 
Scale Veliicle 11”, Thesis for Ocean Engineering, Massachusetts Institute of Technology, Cambridge. MA, Mav 
1998. 
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iterations incorporate greater design detail such as finite element analysis for both static and d>mamic loads. Finally, 
the design incorporates structural arrangement details necessary^ for construction. Each increase in detail requires 
comparison of design characteristics for convergence. The result is a coin ergent. producible design and greater 
confidence with respect to design requirement risk. 



Figure 20 Generic Ship Design Spiral 

There is no one spiral that is correct for all ship designs. A proposed spiral must incorporate design and 
analysis elements necessaiy^ to satisfy requirements. In particular, the spiral task elements may vaiy^ by mission 
requirements, le\'el of risk mitigation required or level of sub-system and total s> stem maturity’. For those general 
design disciplines that are chosen for a given spiral, sub-spirals may be necessary within a design node in order to 
generate and analy7:e specific design characteristics. For example, it is necessary^ to balance auxiliaiv’ system 
capacity' to electrical power generation to payload support requirements w ithin the marine engineering discipline. 
The consequence of layers of design and analysis is a set of nested iterations of design w ithin the o\’erall design 
structure. Figure 21 shows an example of this concept. Additionally, the \ iew of the spiral may change to 
acconmiodate varying process interpretations: viewed as eitlier mo\’ing from the outer nngs inward or from the 
center outward. If outer to inward tlie \ iew is one of considering the initial de\'elopment of numerous conceptual 
designs witli each narrowing ring focusing the effort to few er and fewer design options and culminating in a single 
final design. Alternately, the view of increasing arc lengths from center to outward represents the increasing detail 
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required of each iteration to validate the final design .Whatever the view or structure, the spiral provides a common 
baseline to begin discussion of design process and disciplines necessary to develop and evaluate the design. 



Figure 21 Nested Design Iterations 

These views of the design process are consistent with the basic structure for project models utilized in svstem 
dynamics. Namely, the iterative nature reflects a necessity to take a set of initial (or baseline) tasks to be done, 
perform those tasks to a level of productivity, and rework the tasks due to vaiying levels of design quality. Figure 
22 shows an example of the sv stem dynamics model structure. For naval ship design, the sv stem dynamics variable 
‘initial work to be done" is equivalent to the number of design nodes within the design spiral. Productivity is the 
rate of design accomplishment consistent with the number of designers assigned to and the complexity' of the task. 
Quality' may be interpreted as the rate of design convergence (i.e. the quantity' of tasks requiring re-iteration.) 
Undiscovered rew ork and rework discovery' represent tlie analysis steps of the design spiral Know n rework and 
rework accomplishment represent subsequent iterations of the spiral. 

For typical project management models, tliis sy stem dynamics structure is the basic “engine" for process 
flow. Tlie base structure is then adjusted sy stemically to accomit for the impacts of various project management 
policies. For example, manpower allocation, budget, scope changes, project schedule, ov ertime and others may 
introduce feedback effects on productivity', quality', and work to do. These structures are explored more fully in 
Chapter 5. Process Model Sectors. 

As a basic system dy namics structure (or molecule^"), it is possible to begin using this structure to analyze the 
naval ship design process. However, the design spiral, as presented above, does not completely capture the design 
process. It is necessary' to understand that the spiral interpretation does not fully reflect the method of design used 
by engineers. 


David Brown, “Naval Architecture", Naval Engineers Journal . January' 1993, pages 43-44. 

Jim Hines, “Molecules", a presentation to MTT-Sloan course Application of System Dynamics, Cambridge, MA 
Spring, 1998. 

Tan and Bligh, “A New Approach to an Integrated CAD Method for Surface Ship Design", Naval Engineers 
Journal . January 1998, page 36-37. 
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Figure 22 Generic System Dynamics Project Structure^^ 

Consider a sampling of tasks for a typical ship design (Table 9 and Figure 23.) Tlie listed tasks 
(arrangements, structural analysis, propulsion...) represent specific points on the design spiral. Note that the 
number of issues for each task element are not the same. Each iteration of the design spiral is not equivalent with 
respect to the tasks to be done. Additionally, the time duration of each issue that is performed during a design 
iteration is non-linear (note the numerous slop>e changes in both iteration duration and periods between tasks.) Tliis 
indicates the order of tasks within the spiral is changing. The design spiral is not linear. 


Task 

Preliminary Design 

Contract Design 

General Arrangements 

1250 Hours 

3250 Hours 

- General Arrangements Drawings 

3 Issues 

4 Issues 

- ArcaA^olumc Report 

3 Issues 

4 Issues 

- Personnel Access Study 

1 Issue 

I Update Issue 

Structures 

780 Hours 

2140 Hours 

- Midsliip Section 

2 Issues 

3 Issues 

- Shell Expansion 

1 Issue 

3 Issues 

- Calculation Report 

I Issue 

2 Issues 

Propulsion 

1500 Hours 

3520 Hours 

- Machinery' Arrangement Draw ings 

2 Issues 

4 Issues 

- Endurance Fuel Calculations 

2 Issues 

3 Issues 

Etc... 

Etc... 

Etc... 


Table 9 Sample Task Estimates for an Auxiliary Ship^^ 


James Lyneis, “Calibration of System Dynamic Models", a presentation to MIT-Sloan course Application of 
System Dynamics, Cambridge, MA, April 17, 1998. 
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Design Task Schedule 


I -^General Arrangement Drawings 
;—o—Area/Volume Report 
1—A—Personnel Access Study 
!—x—Midship Section 
J—*— Shell Expansion 

Strength Calculations 
— Machinery Arrangement Drawings 
— Endurance Fuel Calculations 


E 

3 

z 



23-Dec-88 


11-Feb-89 


19-Oct-89 


Figure 23 Sample Design Schedule Estimates for an Auxiliary Ship^^ 

This is a fundamental shortfall in the spiral concept. The spiral portrays the design process as linear. This is 
not the case. The process is better described as “quasi-linear.'’ The progression of tasks normally proceeds in a 
controlled, sequential manner. However, all design tasks within the spiral rely on input from and provide output to 
almost every other node of the process, As such, engineers and designers must have access to information (whether 
actual or estimated) from each design discipline and they must be acutely aware of the potential feedback effects 
caused by the changing output from tlieir own design products. As a result of tliese interrelationslups, tlie spiral is 
actually a network or '‘interaction mesh*' joining design nodes bv' physical relationships and information flows. ^ 
Take a simple example: power balance (Figure 24). Suppose the current iteration of a ship design does not 
acliiev'C desired speed. The current hullform results in required horsepower for speed... approximately a cubic 
relationship. Tlie required horsepower corresponds to a larger propulsion plant concept.. .a non-continuous step 
function. Tlie propulsion plant requires a larger machineiy^ volume and larger displacement... propulsion plant 
power density increases asvmiptoticallv. The hullfomi grow s to acconunodate larger propulsion stack 
length... volume growing as the cube of linear dimensional increases in plant size. Support systems also grow with 
the larger propulsion system and larger hullform... system weights increasing with hull parameters and propulsion 
plant horsepower. The larger hullform results in greater hull weight.. .hull weight increases as L“-L^ and hull 


Ron Nix, ‘T-AG9X PreliminaiyVContract Design Estimates", Naval Sea Systems Command, Januarv' 16, 1987. 
Ibid. 

David Brown, “Naval Architecture'’, Naval Engineers Jounial . Janiiarv' 1993, pages 44-45. 
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surface area increases as L“. The new hullfonn and displacement result in an increase in horsepower required for 
powering at the desired speed... hull resistance increasing in frictional resistance with increased displacement and 
vaning in wave and residual resistance by the choice of hull parameters. The result: increasing power to achieve 
speed can result in a need to furtlier increase power to achieve speed. The key to con\'ergence of tins process will 
depend on the relationship of the various non-linear parameters and the choices of designers to manage feedback of 
those parameters. Also, note that the design process is impacted by many of the disciplines of the spiral (marine 
engineering, hydrodynamics, structural engineering, weight engineering, etc.) and did so in a non-linear sequence. 



Support System 


Figure 24 Simple Iterative Design Network 

Another e.xample of the design process as ‘‘quasi-linear'’ spiral is seen in the application of design s\'nthesis 
software. The Advanced Surface Ship Evaluation Tool (ASSET) is a concept and preliminar\' design synthesis tool 
used by the United State Nav\' to balance and assess ^•arious naval ship concepts. The program is structured as 
presented in Figure 25. The figure shows how, like the spiral, ASSET proceeds sequentially tlirough a series of 
design tasks (called modules) and iterates solutions for a convergent design This progression leads to a linear A'ievv 
of the design process. Figure 25 also show s a sample of the master parameter list (MPL.) The MPL is a product 
model database containing all design attributes used as input and generated as output by the ASSET modules. It is 
the interaction of the sequential modules with the MPL that creates dynamic, non-linear design beha^ ior similar to 
that seen in Figure 24 

To demonstrate this behavior, consider the analysis of the DDG-51 in ASSET. The baseline ship has four GE 
LM-2500 gas turbines propulsion engines with 19220.4 kW each. This results in a total shaft power of 74,974 kW 
and a resultant maximum speed of 31.2 kts. Suppose that a step decrease of propulsion power is proposed by 
replacing the current LM-250() model 30 engines with smaller model 21 engines. The smaller engines proMde 
16032.5 kW each, 62,539 kW total shaft power and a maximum speed of 30.2 kts. The svmthesis of this change 
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requires 5 iterations of the design in ASSET. During each iteration, the ASSET modules modify ship charactenstics 
stored in the MPL and consider the characteristics non-convergent if the values change by more than 0.1% from the 
pre\aous iteration. Table 10 lists those characteristics for each non-convergent iteration that posed the greatest 
differential from the previous iteration. Note that the appendage module com erges faster then the others. Also, the 
auxiliary and weiglit modules are each limited by the same variable: lightsliip weight. The resistance module is 
most limited by effecth e horsepower (EHP) for only the first two iterations while EHP is most hmiting to the 
machineiy^ array for all iterations. Generally, the iterations demonstrate a variation of convergence rates among 
design disciplines, variations of limiting characteristics, and the coupling of design variables among disciplines. In 


other words, the process is non-linear. 


Module 

Iteration 1 

Iteration 2 

Iteration 3 

Iteration 4 

HULL GEOM 

GMT 

GMT 

GMT 

GMT 

HULL SUBDIV 

HULL ARR AREA 

AVAIL 

SHAFT ALLEY 

VOLUME 

SHAFT ALLEY 

VOLUME 

SHAFT ALLEY 

VOLUME 

DECKHOUSE 

AREA BEAM 

AREA BEAM 

AREA BEAM 

AREA BEAM 

HULL STRUCT 

HOGGING EM 

MIDSHIP MOI 

SAGGING BM 

SAGGING BM 

APPENDAGE 

SKEG PROJ 

AREA 

APPENDAGE 

DISP ARRAY 



RESISTANCE 

SHIP EHP 

ARRAY 

SHIP EHP 

ARRAY 

PRPLN SYS 

RESIST ARRAY 

PRPLN SYS 

RESIST ARRAY 

PROPELLER 

PROP RPM 

ARRAY 

PROP RPM 

ARRAY 

PROP RPM 

ARRAY 

PROP RPM 

ARRAY 

MACHINERY 

SHIP EHP 

ARRAY 

SHIP EHP 

ARRAY 

SHIP EHP 

ARRAY 

SHIP EHP 

ARRAY 

AUXILIARY 

LIGHTSHIP WT 

ARRAY 

LIGHTSHIP WT 

ARRAY 

LIGHTSHIP WT 

ARRAY 

LIGHTSHIP WT 

ARRAY 

WEIGHT 

LIGHTSHIP WT 

ARRAY 

LIGHTSHIP WT 

ARRAY 

LIGHTSHIP WT 

ARRAY 

LIGHTSHIP WT 

ARRAY 

SPACE 

DKHS ARR AREA 

OTHER ARR 

OTHER ARR 

OTHER ARR 


REQ 

AREA REQ 

AREA REQ 

AREA REQ 


Table 10 Limiting Characteristics for ASSET Iterations of a Propulsion Change to DDG-51 


A similar non-linear representation of design synthesis can be found in other design tools: GODDESS 
(Goverimient Defense Design for Sliips & Submarines), CONDES (Concept Design Suite) and HFDS (Hull Form 
Definition System.)^^ Thus, like tlie basic design spiral described previously, seemingly linear structures for naval 
ship design s>’ntliesis are actually non-linear in nature. 


Whatmore and Wintersteen, A Review of Extant Design Tool Capabihties to Identify Common Design Tool for 
Future Collaboration, Naval Surface Warfare Center Carderock Division, Bethesda, MD, Febniaiv’ 28, 1997. 
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MONOSC,/MONOLA/MONOCV Modules 


Synthesis Section 



Inout^Output Section 


HULGEN 


EXPORT 


Analysis Section 




PERFORMANCE 




HYDROSTATICS 




SEAKEEPWQ 




SHIP RE Q 

_j SHIP COMMENTS 
J SHIP COMMENT TBL 

Q MISSION 

j SHIP TYPE IND 
J DESIGN MODE IND 
J ENDURDISPIND 
j ENDUR DEFIND 
J ENDURANCE 
J MAX SPEED 
J SUSTN SPEED IND 
J SUSTN SPEED 
J SUSTN SPEED POWER FRAC 
J ENDUR SPEED IND 
J ENDUR SPEED 
J AVIATION FAOLITIES IND 
j EMBARICED COMMANDER IND 
PAYLOAD AND ADJUSTMENTS 
J P^A NAME TBL 
J P*A SWBS KEY TBL 
J P*AWT ADD ARRAY 
_j P-AWT FAC ARRAY 
J P+AVCGKEYTBL 
J P^AVCG ADD ARRAY 
_j P^AVCG FAC ARRAY 
_j P+AAREAKEYTBL 
J P*AAREAADD ARPAY 
_j P+A AREA FAC ARRAY 
J P^AKW ADD ARRAY 
J P*AKW FAC ARRAY 
J HULL 

HULL FORM 
HULL FORM FACTORS 
_j HULL OFFSETS IND 
J HULL DIM IND 
J M'NBEAM 
J MAX BEAM 
J AREA BEAM 
J GMT 
J GMT/BREO 
J FREE SURF COR 
J FAST SHIP PARENT IND 
J FAST SHIP ADJUST ARRAY 
J SERVLIFEKGALW 
J STABILITY IND 
J BULWARK H^ 

J HULL FLAPE ANGLE _ 


Figure 25 ASSET Program Structure and Master Parameter List Example 
In order to properly represent the naval ship design process in a s\'stem dynamics model, there must be an 
accounting of the non-linear interactions seen in the design spiral. A method that can capture this behavior is the 
Design Structure Matrix (DSM.)^^^ First proposed by D. V. Steward in 1981, DSM is a graphically based technique 
to express design process information in a matrix form. The matrix structure shows design tasks by input and output 
relationships. These relationships can be found from physical requirements of engineering as well as procedural 
requirements and structures applied by design managers. 

Consider tlie design tasks discussed pre\iously (Table 9.) The tasks demonstrate a combination of sequential 
and concurrent relationships. Tliese relationships can be captured in a matrix. A possible matrix formulation for tlie 
tasks is shown in Figure 26. The row s are tasks in tlie design sequence with the corresponding columns showing 
those fields that pro\ ide input to the task in the row. The diagonal is assumed to be ‘"0” as a single task should not 
be dependent on itself (note that tliis assumption may not be correct if the design task is itself a compilation of 
smaller tasks.) Each matrix element is represented as binar\-. However, it is possible to furllier refme the “strength” 


Naval Surface Warfare Center Carderock Divisioa “Getting Started & Tutorials: Adv anced Surface Ship 
Evaluation Tool (ASSET) Familv of Ship Design Svmthesis Programs”, September 30, 1997, page 3-29 and page 3- 
22 . 


Eppinger, Wliitney, Smith and Gebala, “A Model-Based Method for Organizing Tasks in Product Dev’elopment”, 
Working Paper, Massachusetts Institute of Teclmology, 1993. 
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of relationships by a percentage of input information required differential change of dependent row on mput column 
or other order of magnitude measure. Ideally, the sequence of rows should form a lower mangle, thus showing 
that tasks proceed sequentially from previous tasks. However, the non-hnear relationships of the naval ship design 
process result in both upper and lower triangle relationships.. .this is called couple development. The ability to 
perform effective concurrent engineering (i.e. maximize productivity and minimize rework) is dependent on the 
level of coupled development, the strength of those relationships, and the ability of engineers to select design lanes 
(initial design assumptions) that minimize iteration differentials. It is further possible to optimize a process by 
rearranging task sequences to minimize the upper triangle against the lower. Such optimization is particularly useful 
for reduction of design code, computational effort and design effort in synthesis of naval ship designs.^^" Ov erall, 
DSM combined with a s>stem dynamics model provides an effective means to represent naval ship process 
dynamics. 
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Figure 26 DSM for Sample Design Tasks 


4.2 Design Disciplines 

With an enhanced understanding of the design spiral, it is necessary to restructure the basic sv stem dv namics 
project management structure to reflect the non-linear process seen in the DSM structure. Additionally, it is 
necessarv' to structure the design tasks in a manner that appreciates tlie multitude of design disciplines applicable to 
the design process and subsequent task accomplishment, without requiring a level of detail that precludes effective 
understanding and exploration (i.e. minimize the DSM structure.) Specifically, the structure must reflect the variety 
of design tasks within a single phase, the inter-relationsliips of those tasks, and tlie growth of tasks (as a function of 
necessary^ design detail) from phase to phase. 

A causal loop diagram is developed to understand the structure that must be included in a naval ship design 
model. Consider the following situation: 

1. Initial iteration begins with a quantity of design tasks. 


Ibid. 

Tan and Bligh. "A New Approach to an Integrated CAD Metliod for Surface Ship Design”, Naval Engineers 
Journal , January 1998, page 35. 
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2. Engineers and managers with specific know ledge of their design disciplines must communicate 
information related to their design tasking to the group in order to provide dependent design tasks with 
input data (establishing design lanes), 

3. Based on the level of organizational communication (ranging from disconnected to fully integrated 
design teams) and the imposed design constraints (such as design requirements and design margins), an 
engineer find that the initial assumptions made to proceed with the design may or may not be accurate at 
the end of the design iteration 

4. As a result of interaction.. .if communication is lacking or the design is not sufficiently constrained then 
the design tasks may be delayed due to competing variations in the initial design assumptions or fail 
entirely due to divergent tasks coupling. 


Figure 27 demonstrates this concept graphically. 



Figure 27 Generic Design Task Relationship 

The rate of design communication and, thus, the rate of design iterations is composed of both controlled 
iterations or "baseline freezes” (those designated instances in the design process during which all design elements 
are frozen to a common set of values) and free iterations (those communications of design change resulting from the 
direct communication of engineers or exchange of design characteristics with a common design product model.) 
'‘Baseline freezes” tvpically occur at predictable rates. An example of the these rates are shown m Table 11. A 
baseline freeze represents a complete design spiral and thus, a complete ship design: but a completed spiral may not 
represent a fully balanced or optimized design. Within the context of DSM, a baseline freeze would be a complete 
sequencing througli the design task matrix. Free iterations occur due to coupled development. Designers from a 
dependent task group communicate at some rate with otlier task groups and update infonnation to maintain accurate 
task data. A slow communication rate will naturally delay the design process. This fact has been noted by the 
method of "over the wall” design. However, commimication at too quick a rate could be equally concerning. 
Specifically, an increased rate results in increased commuiucation overhead Increased commmiication may result 
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in decreased time for productive engineering activities. Additionally, high variations in input data can result in 
instabilities in convergence rates. Iteration rates and communication rates impact the design model. 


Design Phase 

Typical Number Iterations 

Typical Duration 

Concept Design Phase 

10-100 

3-5 days 

Preliminary’ Design Phase 

4-8 

3-6 weeks 

Contract Design Phase 

2-4 

1-3 months 

Detailed Design Phase 

1-2 

1-3 years 


Table 11 Typical Design Iteration Issues and Durations'^^ 


Based on this behavior, it is possible to model the cycle time relationship of task accomplishment with 
respect to design interactions. Tlie following assumptions apply to the development of tlie relationslhps; 

• Only first order relationships are modeled (i.e. hull performance is a function of hull geometr\\ but only 
tlirough the first order translation of hull geometry into seakeeping and resistance attributes) 

• Relationships are considered binary^ (1 or 0) regardless of the degree of relationship. However. 

• Relationsliips judged as existent (1) must be supported by direct physical properties (i.e. SWBS Group 
100 Weight is a direct function of Hull Geometry' parameters and Structural dimensions) or legal and 
management requirements (i.e. all aspects of the design process must provide inputs to the 
progranunatically managed design liistory'.) See Chapter 8.4 for a complete list of references used to 
develop relationships. 

4.3 Design Task Matrix 

Given the non-linearities of the design spiral and the vast quantity of design tasks accomplished during a 
naval ship design (a typical surface combatant design may have over 2,500 separate sliip drawings in detail design 
alone), it is necessary’ to aggregate the tasks into appropriate design nodes. Aggregation allows analysis of dynamic 
interactions and concurrency relationships relative to the design process, while maintaimng manageable quantity’ and 
quality’ for modeling. An analysis of design products (see Chapter 8.4) required at each phase of design (concept 
tlirough manufacturing) and for each system discipline show s that the sy stem disciplines can be grouped into 6 
nodes and 23 sub-nodes. Table 12 shows a listing of the nodes, sub-nodes and a designation code that will be used 
tlirouglioiit tlie remainder of this work and the design model to refer to tlie nodes. 


E.xtrapolated from interv’iews (see Chapter 8.2) and basic design resources (see Chapter 8.4). 
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Designation 

Node 

Sub-Node 

AO 

Programmatic Disciplines 


A1 


Program Management Tasks 

A2 


Requirements & Assessment Tasks 

A3 


Risk Mitigation & Coordination Tasks 

BO 

Systems Engineering 


B1 


Logistics & Reliability' Engineering 

B2 


Design Integration & Specifications 

B3 


Producibility & Production Engineering 

B4 


Performance & Requirements Engineering 

B5 


Manning 

CO 

Hull Systems Engineering 


Cl 


Hull Geometry 

C2 


Weiglit & Stability’ Engineering 

C3 


Hydrodynamics-Resistance 

C4 


Hydrodynamics-Seakeeping 

C5 


Hydrodynamics-Maneuvering & Appendages 

C6 


Structural Engineering 

C7 


Space & Arrangements 

DO 

Machinery^ Systems Engineering 


D1 


Machinery' Systems Design & Integration 

D2 


Propulsion Systems 

D3 


Electrical Systems 

D4 


Auxiliary' & Support Systems 

D5 


Deck. Handling & Aircraft Support Systems 

EO 

Mission Systems Engineering 


El 


Mission Systems Selection, Design & Integration 

E2 


Topside Design & Integration 

FO 

Cost Engineering 


FI 


Cost Estimation & Analysis 


Table 12 Design Process Nodes and Sub-Nodes 
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Task Element 

Program Management Tasks 

Requirements & Assessment 

Risk Mitigation & Coordination 

Logistics and Reliability Engineering 

Design Integration & Specifications 

Producibitity and Production Engineenng 

P erf orman ce-R equirem ents 
Assessment 

Manning 

Hull Geometry 
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Design 
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Hydrodyn a mics-Sea ke epi n g 

H ydrodyn a mics-M an euvenng, 
Appendage 4 Propeller Design 

Structures-Static and Dynamic Design 

Space and Arrangements 

Machinery Systems Design and 
Integration 

Propulsion Systems 

Electrical Systems 
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Analysis of the relationships of these task elements results in the DSM design matnx shown (Figure 28.) 
Figure 29 shows a complete network resulting from the matrix relationships. The outer ring of the network 
represents the traditional, linear design spiral. The interactions represent the range of free iterations possible in the 
process. Chapter 5 discusses the specific approach used to combine the system d\ namics process model with the 
DSM model. The remainder of this chapter addresses the logic supporting the DSM elements and the expected 
behavior resulting from the elements and nodes. 

Before preceding, note that the following assumptions have been made with respect to the DSM structure: 

• The baseline task elements (Table 14 through Table 38) are specific to the DDG-51 program. As such, 
elements for current surface combatant design programs may not be represented 

• The discussions associated with each task node (Sections 4.4 through 4.9) provides a justification for the DSM 
relath e to the DDG-51 task elements as well as highlighting current trends in tasks and interdependencies. 
Future applications of the DSM structure must incorporate dependency shifts resulting from those trends. 



Figure 29 Design Spiral “Interactions” 


4.4 Programmatics 

Programmatics represents the core tasks of eveiy^ naval ship design project. It may also be referred to as 
Acquisition Management. Programmatics contains tasks related to Program Management, Requirements Setting and 
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Assessment, and Risk Mitigation and Coordination. These elements support the creation of a design and acquisition 
program, management of the design and contract award oversight of the production design and construction, and 
engineering support to the operational forces throughout the life cycle of the ship. Specific programmatic tasks are 
required by DoD Instruction 5000.2 (Defense Acquisition Management Policies and Procedures) and DoD Manual 
5000.2 M (Defense Acquisition Management Documentation.) A complete listing of applicable directives is found 
in tlie Defense Acquisition Deskbook ( ]ntp:/Au\w.deskbook.osd.mil. ) Additionally, tasks are necessitated by good 
engineering and business practice such as maintaining a design history or managing scope growth. 

The elements of programmatics were under fire in recent years due to perceived inefficiencies. As tlie 
fundamental decision-making support systems, programmatic tasks have seen a natural growth in project 
deliverables. This growth correlates to increasing teclmological design risk and pressure to decrease design cost (see 
discussion of externalities in Chapter 2.) The result is increasing time required to prepare documentation (Table 13.) 
Figure 30 shows task efforts (averages for 45 Navy, ACATI design programs) expended for key programmatic 
deliverables. As the key inputs to program milestones, there has traditionally been a need to produce significant 
portions of tlicse documents prior to each review stage, which may include as many as ten different review and 
approval levels.The combination of multiple decision layers and increasing programmatic efforts is \iewed as a 
key factor contributing to the growth of the design cycle. 


Ship Program 

Prcliminar\' Design 

Contact Design 

DDG-993 

N/A 

1,454 

CG-47 

1.818 

8,147 

DDG-51 

2,696 

23,654 


Table 13 Programmatic Man-hour Effort Trends'®^ 


William Ball, '‘DoD Acquisition Policy and the Effect on Naval Ship DcsigC, Society of Naval Architecture and 
Marine Engineering, February 25, 1992, page 7-5. 

Ship Design Group, Ship Design Project Histories: Volume I, II and III , Naval Sea Systems Command 
September 1978, May 1986 and August 1996. 
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Figure 30 Average Programmatic Documentation Effort^^^ 

To counter these trends, significant changes were implemented with respect to programmatics. As part of 
acquisition reform iniuatives (see Chapter 1.11), contract specifications, programmatic deliverables and design 
reviews were modified to remove redundancies and outdated requirements. In particular, program managers are 
granted greater authority to reduce documentation requirements and wai\'e redundant design reviews entirely. These 
changes have significant impacts (positive and negative) on design programs. For instance, the LPD-17 contract 
design effort was negatively impacted when a directive to reduce contract specifications was implemented well into 
the design process. Although tlie effort reduced contract deliverables (reduction from 1,452 to 327 specifications), 
thus impro\ing efficiency in lead ship design, contract design efforts were delayed several montlis to implement the 
reform (the effort was referred to as “triage”.)^Conversely, reforms allow programs, such as the current DD-21 
program, to realize improved management efficiency and reduced review periods. These cases indicate that 
implementation of programmatic reforms may dynamically impact a project. 

In order to simulate programmatic fluctuations within the design model, the following assmnptions w ill be 

made: 

1. Total programmatic requirements (number of tasks at each design pliasc) are fixed initially for the model 

2. A capability to generate random and/or specified growth and decay of programmatic tasking is included 

Values for baseline productivity- and task levels are provided in Chapter 8.5. 


RAJDM Roger B. Home, “Concept to Commissioning, Improving the Ship Design, Acquisition and Construction 
Process: Strategic Plan”, Naval Sea Systems Command, Washington. DC, June 1991, III-2.3.11. 

Fireman, Fowler, Meintire and Wilkms, “LPD 17: In the Midst of Refomi”, Naval Engineers Journal . May 1995, 
page 267. 

108 Dennis Mahoney (USN), former DD-21 Program Manager, interviews during Spring 1998. 
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4.4.1 Program Management Tasks 

Program management centers on five key areas; planning, controlling, organizing, staffing and leading. 
Planning includes all those acthities associated with the acquisition strategy and program schedule. The major task 
element for program management in a modem ship design program is the Acquisition Program Baseline (APB). 

The APB establishes the metrics to measure perfomiance, cost and schedule for the acquisition program and 
includes objective and threshold components. The APB is a living document that is adjusted and acted upon based 
on the influence of design changes, w arfare requirements and schedule pressures. The APB is the primaiy^ 
documentation for review and approval (SAR and DAES.) The APB development and approval process is 
demonstrated in Figure 63. Specific instructions for preparation of the APB are found in DoD Directive 5000.2. 

Controlling tasks are those elements necessary to monitor conformance of program performance to the 
guidance of authorities and the APB. The use of Cost/Schedule Control System Criteria (C/SCSC) may be utilized 
to “detect a deviation from the plan, (acth ate) a control mechanism to bring the system back into line.”^^^ 
Specifically, controlling requires continual audit of program processes to monitor and correct process performance. 

Organizing and staffing involve the management of personnel and manpow er budgets with respect to the 
design process needs. This is a major s> stemic force in the design process. As such, it is explicitly modeled beyond 
tasking requirements (see Chapters 5.4 and 5.5.) 

Finally, leadersliip is the major function of the program management staff. The ability to clearly 
communicate desired program direction, goals and needs is critical to program performance. Leading the program 
entails continuous information gatliering and evaluation with respect to the forces acting to control the program (see 
Chapter 2). As a result of the program managers perceptions of those forces, he or she must respond by marketing 
the good aspects of the program and addressing concerns to responsible autliorities. In a teaming en\ironment, as 
proposed by IPPD/IPT. program leadership means the ability to establish and maintain consensus. A program 
manager is by definition the leader of the design program, and it is his or her continuous role (and tlius tasking) to 
lead and guide a successftil acquisition program. To implement leadership over all aspects of the project, program 
management will naturally require input and output connections to all design disciplines 


Defense Management College. “The Program Manager's Notebook*’, Fort Belvoir, VA, June 1993. 
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Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Acquisition Program Baseline (AP) 

1 

1 

1 

1 

1 

1 

1 

Acquisition Strategy 

1 

1 

1 

1 

1 

1 

1 

Acquisition Decision Memorandum (ADM) & 
Defense Acquisition Executive Summary (DAES) 

1 

1 

1 

1 

1 

1 

1 

Program Management 

1 

1 

1 

1 

1 

1 

1 

Milestone Preparation and Exit Critena Satisfaction 

1 

1 

1 

1 

1 

1 

1 

Security & Security Protection Strategy 

1 

1 

1 

1 

1 

1 

1 

Legal Issues Analysis 

1 

1 

1 

1 

1 

1 

1 

Treaty Compliance Assessment 

1 

1 

1 

1 

1 

1 

1 

SHAPM Support & Special Studies 


1 

1 

1 

1 

1 

1 

Design History 


1 

1 

1 

1 

1 

1 

Design Site Management 



1 

1 

1 

1 

1 

Hull Engineering Task Group Support 



1 

1 

1 

1 

1 

Machinery Task Group Support 



1 

1 

1 

1 

1 

Deaqn Control 





1 

1 

1 


Table 14 Program Management Tasking 

Based on analysis of the DDG-51 program and other surface combatant projects, a general listing of program 

management tasks is developed. 

Table 14 shows the appropriate design phase during wliich specific program management tasks are activated. 
It is assumed that tasks are updated at each design stage. The list is not all-inclusive (nor are later hsts in this 
chapter), but does represent those primary' task elements required by directive or good engineering and management 
practice (see Chapter 8.5.) For purposes of the design model, the given quantity' of tasks (along with total 
programmatic man-hours expended) provides sufficient aggregate detail to model process behavior. With respect to 
the DSM structure, the command and control nature of program management necessitates complete input from and 
output to all design disciplines. As such, the row and column is unity' (see Figure 28.) 

4.4.2 Requirements Setting and Assessment 

The second program task element is tlie interface between the designers and the warfighters: requirements 
setting and assessment. The primary' concern of requirements is the definition of the defense-technical problem and 
translatmg tliis problem into a potential design. Chapter 1.12 specifically addresses the current mechanisms being 
applied to improve problem definition and translation. Additionally, there are a number of specific design 
deliverables that relate to those mechanisms. The Mission Need Statement (MNS) and Operational Requirements 
Document (ORD) are the initial documents produced in tliis discipline. The MNS in a non-sy stem specific 
statement of operational capability'. Tlie ORD fomially states warfighter objectives and minimum acceptable 
requirements for operational effectiveness of a proposed ship concept and its associated systems. Based on the 
requu-ements of the MNS and ORD, an AoA (fomierly COEA) study' is performed to analy'ze potential sy stem 
options satisfying the requirements. The AoA as defined here is not the act of concept engineering analysis, but 
rather the accumulation of infonnation developed by specific engineering disciplines in response to the stated needs 
of the MNS and ORD. In other words, the AoA is a document or task requirement, not a process. Instead concept 
and preliminary' design arc the processes by which AoA tasking is implemented. Figure 61, Figure 62, and Figure 
64 show specific processes by which these documents are prepared and review ed. Tlicse requirements and post 
engineering assessments are continually audited to ensure the design meets tlie needs of operational forces. 
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When deficiencies are discovered the program manager has three primaiy options: modify the mission 
requirements, re-initiate the design to achieve the stated need or introduce an engineering change to achieve the 
stated need Modification of mission needs is a relatively detailed process, but can be effective in the veiy early 
stages of design. This is particularly true during concept design if the design community (in conjunction with AoA 
tasking) is given an opportunity to present operational forces with specific design trades enabled by requirement 
changes. The approaches presented in Chapter 1.1.2 demonstrate the effectiveness of this approach. If operational 
needs cannot be changed then the design may need to be re-initiated. There are numerous examples of this 
approach in tlie last few years as a result of changes in defense doctrine and force structure. For instance, the DDG- 
51 Fliglit IIA program is a direct result of a need to produce substantial improvements to the DDG-51 program 
following decommissionings of numerous combatant ship classes during the early 1990's. This option is not 
practical miless the design process is still young (the DDG-51 concept design process lasted four years for this 
reason) or the requirements changes preclude reasonable design modification within the current program (DDG-51 
Flight IIA.) When changes are moderate, then engineering change proposals (ECPs) may be used. Once again, 
early introduction of ECPs is preferred. Due to the long duration of naval ship design projects, it is inevitable that 
changes are required. Tliese changes hav e well documented negative impacts on the design process (see Chapter 
1.1.2.) Tliere are methodologies which can minimize the impact of design change including: Open Architecture and 
Modularity. Ultimately, the program manager must decide whether the timing and performance gains of a given 
design change outweigh the impacts to schedule and cost. 

For the purposes of the naval ship design model, these tasks and behaviors are incorporated as follows: 

1. Tasks profiles are set per those listed in Table 15 

2 . ECPs are introduced by random and/or specified task growth to the initial tasks 

3. Tlie fraction of task growth from ECPs is directly determined by the first order impacts of the scope 
growth being introduced (i.e. a design with open architecture would see a substantially smaller task 
fraction increase than a design without change mitigation mechanisms.) 


Like tlie structiue for program management, requirements setting indicates a direct output to all design tasks 
and assessment of those requirements requires input from all tasks. Tlius, tlie DSM structure is fully populated. 


TasK Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Decision Coordination Paper (DCP) 

1 

1 

1 

1 

1 

1 

1 

Selected Acquisition Report (SAR) 

1 

1 

1 

1 

1 

1 

1 

Congressional Data Sheet (CDS) 

1 

1 

1 

1 

1 

1 

1 

Mission Need Statement 

1 

1 

1 

1 

1 

1 

1 

Operational Requirments Document (ORD) & Requirements Setting 

1 

1 

1 

1 

1 

1 

1 

System Concept Paper (SCP) & Design Review/Report 

1 

1 

1 

1 

1 

1 

1 

System Threat Assessment 

1 

1 

1 

1 

1 

1 

1 

COEA/Analysis of Alternatives 

1 

1 

1 

1 

1 

1 

1 

Engineering Change Proposals (ECP) & "Externar Change Requests 






1 

1 


Table 15 Requirements Setting and Assessment Tasks 


MIT Course 13.64, “CVX Product and Process Plamiing", Massachusetts Institute of Teclmologv, Cambridge, 
MA, Summer 1997, page 70. 
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4.4.3 Risk Mitigation and Coordination 


The final category of programmalics is that set of tasks which provides analysis of potential program risks 
and coordinates technology development with other defense programs. Primary tasks in this category are: 
Development Test and Evaluation (DT&E), Test & Evaluation Master Plan (TEMP), Live Fire Test & Evaluation 
(LFT&E) analysis. Safety analysis and coordination efforts for Research, Development, Test and Evaluation 
(RDT&E). DT&E determines the potential variabihty in effectiveness, cost and schedule associated Mth 
technologies under consideration for tlie design. If the technologies are too risky for consideration, fail-back options 
are explored to allow the design to proceed. DT&E changes can impact the design rates through the introduction of 
delayed tasks (technologies maturing behind schedule) or scope change (transition of the program to the fallback 
position or introduction of a newly maturing technology.) Even after specific technologies are introduced into the 
design, it is necessaiy^ to develop a schedule to evaluate the effectiveness of the technology as integrated in the ship 
design. Specifically, the TEMP and LFT&E provide the structure to test sy stem effectiveness. As known and 
perceived risks relative to the technology or capability are disclosed, the plans must adapt. An increasingly 
important method of risk reduction is coordination of RDT&E w ith other programs. In particular, early R&D 
projects must be monitored to ensure compatibility with ship design development and mission needs. For more 
ach anced technolog>^ programs. Ship Acquisition Managers (SHAPMs) must coordinate efforts with Participating 


Managers (PARMs). Once again, changing technolog>' schedules and capabilities may impact the design process. 


Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Risk Assessment 

1 

1 

1 

1 

1 

1 

1 

Programmatic Measures of Effectiveness Analysis (Cost Schedule & 
Performance Risk Analysis) 

1 

1 

1 

1 

1 

1 

1 

DT&E Report 

1 

1 

1 

1 

1 

1 

1 

Environmental, Safety & Health Evaluation 

1 

1 

1 

1 

1 

1 

1 

Technology & Industrial Capability Assessment (Commercial & NDl 

Evaluation & Status) 

1 

1 

1 

1 

1 

1 

1 

Cooperative Opportunities Assessment 

1 

1 

1 

1 

i 

1 

1 

Integrated R&D 

1 

1 

1 

1 

1 

1 

1 

Test & Evaluation Master Plans (TEMP) 

1 

1 

1 

1 

1 

1 

1 

LFT&E Waiver Certificate 

1 

1 

1 

1 

1 

1 

1 

LFT&E Report 

1 

1 

1 

1 

1 

1 

1 

Computer Applications & Support. Information Technology Architecture 

1 

1 

1 

1 

1 

1 

1 

Information Technology Statutory Compliance (Information Technology 

Management Reform Act (ITMRA), Government Performance and Results 
Act (GPRA), Paperwork Reduction Act (PRA)) 

1 

1 

1 

1 

1 

1 

1 

System Safety Study 


1 

1 

1 

1 

1 

1 


Table 16 Risk Mitigation and Coordination Tasks 

For tlie purposes of the naval ship design model, these tasks and behav iors are incorporated as follows: 

1. Tasks profiles are set per those listed in Table 16 

2 . Clianges resulting from technology changes are introduced b\' random and/or specified task growth to the 
initial tasks 

The DSM structure for risk mitigation deviates slightly from previous programmatic tasks. Process flows 
indicate that although risk tasking is performed for specific engineering disciplines (hull, machinerv’, payloads, 
system, cost), the risk analysis information is delivered tlirough program management and requirements rather tlian 
directly to the responsible disciplines. In this manner, risk mitigation and coordination acts as an information 
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control gate dunng feedback of design attributes. As assessments of requirements against presented design 
parameters are assimilated the elements of risk mitigation incorporate those values. If specific nsk analysis 
indicates concerns or necessary coordination, then modifying information will flow back to those disciplines that 
perform physical design (hull geometry, mechanical s\'stcms, mission s>stems, etc.) 

4.5 Systems Engineering 

The second design process node is s>'stems engineering. It is important to differentiate systems engineering 
as discussed in Chapter 3 from this process node. System engineering as discussed previously represents the 
overarching optimization of cost, effectiveness and schedule to meet a need. In this context, the naval ship design 
process is a subset of systems engineering. However, witliin naval ship design is an alternative systems engineering 
definition. In this context, s\ stems engineering represents those engineering disciplines required to integrate 
specific ship design components (hull sy stems, mechanical sy stems, and combat sy stems), to analy7;e the integrated 
components in the sy stem (Integrated Logistics Support (ILS), contract specifications, producibility, manning) and 
to compare the sy stem performance against requirements (mission effecti\'eness.) In tliis context, sy stems 
engineering has evolved over the last 40 years to become a key clement of the design process. Initial fonnalization 
of systems engineering began in the 1950's on the first balhstic missile programs. During the 1970’s, sy stems 
engineering achie\'ed true maturity' in the Aegis Weapons Program (1970’s) under the guidance of ADM Wayne 
Meyers (USN retired.) During an interx iew with ADM Meyers^ he made tlie following comments regarding the 
impacts of sy stems engineering on the overall design process: 

1. “Warsliips are inherently inefficient design exercises.” Due to the scope of surface combatant design 
projects, indi\idual design components are rarely optimized in the context of system impacts. For 
instance, component optimization generates vast numbers of supplier-vendors. A large vendor base 
requires complex supply chains which dc-optiniize ILS and life cycle cost. Until effective system 
optimization is realized (see Chapter 1.1,2). component development will continually generate 
divergences in sy stems development. 

2. “Program managers don't know, only perceive, the true status of the fiscal technical, temporal vectors.” 
The goal of the program manager is to focus the project towards con\'ergence. However, uncertainties in 
information, vanations in cost, and delays in progress cause the vectors to diverge. In sy stems 
engineering, this is even more critical as the integration of components is constantly \'ary ing w itli the 
variable schedules and complexities of those components (Figure 23 and Tabic 9.) Coupled productivity 
and v ary ing development rates produce delays in sy stems development. 

3. “Know ledge... Engineering, Cost, etc... must be accumulated and tapped to facilitate sy stems 
integration.” Systems engineering is the cap-stone of the naval engineering process. To effectively pull 
together the elements of the system, time and patience are necessary. Unfortunately, time is also the 
enemy of the design process... time generates changing requirements and changing technologies. To 


ADM WayTie Meyers (USN retired), interview on November 14, 1997, Arlington, VA. 
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understand s\stems engineenng one must acknowledge the impact of time.. early work is undone, later 
w ork will require iteration back to the component level, and ver\^ late work will introduce scope 
increases which can diverge the program. 

Baseline (DDG-51) task levels and productivity levels for Systems Engineering are presented in Chapter 8.5. 

4.5,1 Logistics and Reliability Engineering 

Integrated Logistics Support (ILS) and Reliability, Maintainabihty' and Availability (RMA) assessment are 
the disciplines that may most greatly determine tlie life cycle cost and operational effectiveness of the ship design. 
ILS is a management and technical approach that integrates support considerations into system and equipment 
design. Support requirements are determined by readiness objectives, current and planned supply chains (underway 
replenishment, storage, supply overhead, packaging, handling), maintenance plans, manning levels, and training 
pipelines. RMA (also known as RAM) is a complement to ILS. RMA analysis determines the level of ILS required. 
Specifically, RMA assesses operational functionally for the sliip, redundancy versus rehability, and the ease of 
recover^' of systems that do fail (relative to ILS and maintainability.) 


Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Integrated Logistic Support & Maintenance Analysis 

1 

1 

1 

1 

1 

1 

1 

Reliability, Maintainability and Availability (RMA) Assessment 

1 

1 

1 

1 

1 

1 

1 


Table 17 Logistics and Reliability Engineering Tasks 
RMA and ILS are highly coupled disciplines. As such, it is not unreasonable to assign a value of 1 to the 
diagonal for DSM (see Chapter 4.1.) However, tlie value of 0 is assigned to maintain consistency with DSM 
methodology. Input values are required from those disciphnes that impact maintenance, reliability and support 
including, requirements, manning, hull structures, arrangements, mechanical and mission systems. The results of 
ILS and RMA feed programmatics for action, if necessaiy. Additionally, results provide input to producibility^ (ILS 
has a first order impact on production methods) and to performance (RMA is an input for Ship Vulnerability' 
Modeling (SVM) and operational effectiveness measures.) 

As w ould be expected. ILS and RMA should be started from tlie initiation of the design in order to achieve 
the greatest leverage over life cycle cost (LCC). Table 17 shows the progression of ILS and RMA tasks. Past design 
programs minimized the early ELS and RMA effort. This can be seen by the small man-months per task during 
concept and preliminaiy design shown in Chapter 8.5. Given current ILS trends, there is increased need for early 
analysis. Figure 31 shows the exponential growth experienced in ILS o\ erhead measured as increasing parts listings 
(APL’s.) With increasing parts and supply trains, ILS becomes an increasingly greater fraction of LCC. As shown 
in Figure 32, the primar\' ILS components (manning and maintenance) constitute almost 60% of the LCC. Recent 
efforts to coimter the trend (such as Affordability Through Commonality (ATC) and open systems architecture) 
show' promise. Applied to current design programs, these efforts provide substantial cost sa\ings, but require greater 
man-hour efforts in early design. For the baseline design model, DDG-51 ILS task efforts are used. However, 
future "w hat-if' scenarios should reflect increased efforts in early stage design. Tliis would provide program 
managers with a comparison of life cycle cost savings v ersus the impact on schedule and resources. 
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Figure 31 Trends for Applicable Parts Lists (APL’s) for Surface Combatant Designs^^^ 



Personnel 
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Design 
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Modernization 
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Maintenance 
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Figure 32 Life Cycle Cost Components for Typical Naval Ships^^^ 

4.5.2 Design Integration and Specifications 

Design integration and specifications are the means by which the design achieves system definition and seeks 
to maintain designed performance in subsequent iterations. In the early stages of design, s> stems engineering 
decisions are meant to define the overall ability of concepts to satisfy expectations for total s> stem effectiveness. As 
specific ship components (hull, prime movers, combat system elements) are considered in the design, these elements 
must be optimized relative to one another and relative to mission requirements. As design iterations are generated, 
there may be the tendency* of component engineers to continuously change in response to changing input 

Todd Can’, Naval Sea Systems Conmiand, inteniew on August 27, 1997, Arlington, VA. 

Ryan and Jons, '‘Improving the Ship Design. Acquisition and Construction Process", Association of Scientists 
and Engineers, 28^^ Annual Teclinical Symposium, 11 April 1991, page 13. 
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information from other component elements. Without mechanisms to manage these changes, it is likely that the 
design would diverge. This is the role of systems integration. Througli the use of margms (see Chapter 1.1.3) and 
configuration control, design managers restrict the degree of change permitted over time. Configuration control 
(managed by means of a baseline 3-D product model, equipment lists, performance specifications, mihtan' 
specification, issuing arrangement drawings, etc) provides a design baseline that “freezes" those aspects of the 
design viewed as satisfactory with respect to the requirements. 

In later design stages, design integration matures beyond configuration specification to component 
specification. Earlier discussions (see Chapters 3.3.1 and 4.4) demonstrate the changing roles of contract 
specifications in the design process. Howe\’er, the selection of components and their exclusion from further design 
change must take place in the design process, whether dictated by the government during contract design or b\' 
industiy^ in functional design. Ultimately, the design must be specified in order to allow' production. 


Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Systems Engineering, Design Integration & Configuratton Control 

1 

1 

1 

1 

1 

1 

1 

Ship & Purchase Specifications, GFE/GFI & CDRLs 


1 

1 

1 

1 

1 

1 

Specification Design History Input 


1 

1 

1 

1 

1 

1 

GFE'GFIA/FI Specification 



1 

1 

1 

1 

1 

Design Control 





1 

1 

1 


Table 18 Design Integration and Specification Tasks 

Table 18 provides a listing of the specific design tasks associated with design integration and specification. 
Note tliat tliese task effort profiles (Chapter 8.5) would likely change for a current design program to reflect a 
changing government to industry design transition point (see Figure 5). However the task elements (with perhaps 
different names) would still remain. 

Tlie input requirements for design integration include tliose elements of the process that are specific to design 
definition (hull, structures, marine systems, combat systems.) The design integration tasking receives the inputs of 
current design parameters and outputs constraints to the program manager for implementation. 

4.5.3 Producibility and Production Engineering 

Producibilih' and production engineering is the consideration of industrial capabilities relative to ship design 
and construction Tliis requires both the assessment of industrial capabilities relative to technologies incorporated in 
the design and inclusion of “design for production'’ elements in the design. To tlie first requirements, the industrial 
base necessarv' to support naval ship design and construction must be assessed. For instance, tliere only a few 
shipbuilders witli facilities, knowledge and skills av ailable to produce specialized huUforms (such as submarines) or 
to test advanced combat sv stems (such as the Aegis Weapons Sv stem.) The selection of specific ship design options 
(such as materials, size, weapon sv stems, etc) will naturally reduce the field of potential builders. Tlie introduction 
of new technologies may further reduce the capable industrial base. It is a necessaiy' task of design managers to 
understand tlie impacts of technolog> and design on the shipbuilders. Secondly, design for production must be 
included to achieve the cost goals described in Cliapter 1.1.3. Specifically, the design must: 

1. Dev elop a build strategy and product work breakdown structure. 
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2. Assess the design against the production process 

3. Incorporate appropriate producibility enhancements. 

It IS apparent that this process of design for production is itself a closed loop system that seeks to optimize cost and 
production effectiveness relative to military effectiveness. 

It is noted tliat design for production considerations were not adequately included in past designs. Due to 
requirements for competition, US yards have not been able to incorporate producibility to the extent necessar>’ to 
realize savings. Consider Table 19. In foreign yards, designs are specifically tailored to the capabilities of the yards 
and their workers. As such, e\^en in countries where workers are paid more, the labor required to produce a ship and 
the total labor costs are less. Consider the design task elements for the DDG-51, and hence the baseline naval ship 
design process model, shown in Table 20. The ship work breakdow n structure was not formalized until late in the 
process. Again demonstrating tlie lack of producibility consideration in the fmal design. 


Productivity 

Japan 

Korea 

Germany 

us 

Employee-Days/Ship 

45,000 

99.000 

65,000 

100.000 

Hourly Compensation (1990 US Dollars) 

16.0 

7.8 

26.5 

15.6 

Total Labor Charges ($ million) 

5.76 

6.17 

13.78 

12.48 


Table 19 Shipyard Productivity Comparison for Comparable Ship Designs^^^ 


Tliere are significant efforts to change this trend and to incorporate producibility much earlier in the design 
process. For instance, the LPD-17 hiillform design was enhanced w ith large flat plate construction, single cuiv ature 
midbody and an elliptical bulbous bow (no fillet).^These enhances are a step in tlie direction of enliancing 
producibility. Current programs will furtlier improve producibility by incorporating sliipbuilders at the earliest 
stages of design. 

To maximize the leverage of producibility on cost, a ship design must be optimb.ed from the concept phase 
onward not only for mission needs and operational cost, but also for production schedule and construction cost. 
Producibility tasking may take several forms, but two are generally obseiv ed. First, producibility is assessed relati\'e 
to fabncation, arrangements and materials. For those designs that are optimized for a particular shipyard’s 
capabilities, ship arrangements (outfitting, block sizes, etc) and materials and fabrication (common material 
catalogue, limiting complex shape geometry ) enhance productivity for the shipbuilder. Impro\ed producti\ity 
means lower costs, better quality and shorter production schedules. 


Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

industria! Facilities Design and Industrial Base Assessment (BASE) 

1 

1 

1 

1 

1 

1 

1 

Producibility. Fabrication & Materials Assessment 


1 

1 

1 

1 

1 

1 

Ship Work Breakdown Structure 




1 

1 

1 

1 


Table 20 Producibility and Production Engineering 


Rost and Tighe, 1992 Shipyard Costs and Capabilities , Center for Na\al Analysis, Alexandria. VA. 

Fireman, Fowler, Mclntire and Wilkins, ‘'LPD 17: In the Midst of Reform”, Naval Engineers Journal , May 1995, 
page 275. 
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However, competitive requirements of contracts necessarily limit the level of producibility optimization that 
can occur. For this reason, a second method of producibiliu^ assessment has been developed: Generic Work 
Breakdown Structure (GWBS). As its name implies, the method provides a generic method of assessing 
producibility. The method is centered around group technology construction and organization of design elements 
into families of structures and components.^ For early design (pre-contract award) the method provides a tool to 
assess production impacts of design decisions and to minimize costs where possible. 

For the design model, Table 20 provides the baseline progression of design tasks. Again, current design 
programs will see variations in the timing of design tasks and growth in the lev els of producibility tasks. 
Dynamically, producibility incorporates specific slhp characteristics (liuU geometrv\ structural design, arrangements, 
machinery and payload components) to assess construction impacts. Tlie output of producibility is assessed at tlie 
management level. Additionally, producibility is a key input factor to cost assessment. 

4.5.4 Performance Assessment and Requirements Comparison 

Performance assessment includes modeling design characteristics as a total s>stem, calculating ship's 
performance based on total ship design parameters, and assessing tlie mission effectiveness relativ e to requirements. 
Performance assessment has improved in recent years through improv ements in computer modeling capabilities. 
Specifically. Survivability and Vulnerability Modeling (S VM), Electromagnetic Workstation (EMW) models. 
Leading Edge Advanced Prototyping for Ships (LEAPS), and others provide increasingly robust environments to 
test s)'Stem performance and effectiveness.These models are the initial steps of a trend towards simulation based 
design (SBD.) Although, most levels of performance assessment still require physical modeling (such as hullform 
testing in towing tanks), improved computer modeling will eventually provide the means to test all performance 
requirements in the virtual environment. 


Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Survivability & Vulnerability Assessment 

1 

1 

1 

1 

1 

1 

1 

Concept Performance 

1 

1 

1 

1 

1 

1 

1 

Damage Control System Design 

1 

1 

1 

1 

1 

1 

1 

NBC (CBR) Defense 

1 

1 

1 

1 

1 

1 

1 

Combat System Performance Assessment 

i 

1 

1 

1 

1 

1 

1 


Table 21 Performance Assessment and Requirements Comparison Tasks 
Table 21 shows a progression of performance tasking that w as performed for the DDG-51 program. The DD- 
21 program will include mission effectiveness assessment and task efforts such as: Extended Air Defense Simulation 
Model (EADSIM), Surface AAW Multi-Ship Simulation (SAMS). Naval Air Battle Engagement Model (NABEM 
11), Radar Analysis Model (RAM), AS W Programs Surface Ship Engagement Model (APSURF), and Genenc Sonar 
Model (GSM) 


Storch, Hamition, Bunch and Moore, Sliip Production . Society of Naval Arcliitects and Marine Engineers. Jersey 
City, NJ, 1995, page 60. 

' Myles Hurwitz, ‘'Leading Edge Advanced Prototyping for Ships (LEAPS): an Integrated Architecture for Early 
Stage Ship Concept Assessment Software”, David Taylor Research Center, Betliesda, MD, 1997. 

DD-21 Program Website, http.7Avv\w.navsea.navy^mil. 
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Like other systems engineering disciplines, performance assessment requires input from all design definition 
disciplines. However, the output of assessment is often provided directly to designers. This is particularly true in 
the real-time design and selection of specific design characteristics such as arrangements, hull and deckhouse 
configuration and topside arrangement of combat systems. 

4.5.5 Manning 

Mamiing assessment and definition is the final discipline of sy stems engineermg. Manpower studies begin 
with comparative estimates of ship functions to similar ship designs. Later studies provide detailed manning studies 
based on functional breakdowTis of manning requirements. As manning levels are established for specific ship 
watch stations, human engineering are conducted to optimize human performance relative to mission performance. 

For many years, manning was \iew'ed as a non-constraining attribute. Namely, sliipboard manpower was 
viewed as unlimited. Damage control, condition I w atch stations and maintenance requirements often drove 
manning levels well above those levels required for daily operations. However, the fiscal need for reduced 
operational costs and the political desire to limit human exposure to threat environments now results in imposed 
manning levels. If this trend continues, maiming assessment becomes increasingly important to both s\ stem and 
component design. 


Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Manpower Estimate 

1 

1 

1 

1 

1 

1 

1 

Manning Study 

1 

1 

1 

1 

1 

1 

1 

Ship Manning Document 


1 

1 

1 

1 

1 

1 

Human Systems (Factors) Engineering 


1 

1 

1 

1 

1 

1 


Table 22 Manning Assessment Tasks 

Table 22 show s the progression of manning tasks. Tliese tasks require input primarily of those ship 
characteristics that impact human engineering and mamiing requirements including: ship arrangements and sizing. 
machineiV' sv stems and combat sy stems. Early output from manning impacts sizing of the hull, payloads and 
auxiliaiv' systems. Later output provides specific requirements for accommodations (arrangements), machineiv' 
system modifications for human support and second order changes (changing maintenance requirements or selection 
of new' equipment items) tlirougli program management. 

4.6 Hull Engineering 

The hull engineering node is itself a significant systems engineering effort. Na\'al architects, the primaiv' 
participants in hull engineering, often claim the title of the "world's first systems engineers.Specifically, hull 
engineering must balance weight, buoyancy, area, power and resistance w hile maintaining adequate static and 
dynamic stability and strength, both in intact and damaged conditions. Specific design spirals are developed to 
balance these characteristics. For instance, the MIT Math Model - FFX'^^, balances hull characteristics, deckhouse 

Tibbitts and Keane, "Naval Ship Design in the 2r^ Centuiy '’, Society of Naval Architects and Marine Engineers, 
Jersey City , NJ, 1993. 

Brown and Welsh, MIT Math Model - FFX, Massachusetts Institute of Teclmolog\' course 13.412, fall 1996. 
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v olume and power for fixed inputs of marine sv stems, combat payloads, mission requirements, and maiming. The 
original design spiral dev eloped by Prof Evans performed a similar optimization for commercial ship designs. A 
specific examination of equations and physical relationships for hull design and engineering are beyond the scope of 
tiiis work. Rather, the nature of the component design disciplines and tlieir purposes relative to the design process 
are discussed. 

It is important to note a general cliaiige in hull engineering disciplines over the past decades. In the past, 
arrangements and hull geometry' and powering were often separate exercises from hydrostatic and hydrodynamic 
analysis. Although it was possible that the same indiv idual or group of individuals might perform the design and 
analysis tasks, the considerable manual effort required to perform tliose tasks would necessarily cause them to be 
performed independently. This fact is apparent in IDEF charts and design spirals depicting very linear and distinct 
nodes. For instance. Prof Evans design spiral generates a basic ship design from^^^: 

1. Proportions and Powering Estimates 

2. Lines and Body Plans 

3. Hydrostatics and Bonjeans 

4. Floodable Length and Freeboard 

5. Arrangements 

6. Structures 

7. Powering Light Ship Weight Estimates 

8. Capacities. Trim and Intact Stabilitv' 

9. Damaged Stability' 

10. Comparisons to Cost and Owners Requirements 

11. Nexl Iteration... 

This indicates an algoritlim by which design disciplines are separated or design tasks are linear. However, today’s 
design tools are allowing seamless design and analysis with real-time iteration and feedback. For instance, hull 
geometrv' software often includes modules to create hullforms, assess resistance, generate hydrostatic properties, 
assess maneuv erability and detennine seakeeping. These integrated packages allow a single designer to 
inmiediately see the impact of a hull geometry change on resistance or buoyancy. Inclusion of internal properties 
(hull subdivision, weight distributions and tank placements) allow a designer to perform major arrangements and 
assess those choices for stability. Obviously, the advantage of the integrated env ironment is fewer design errors, 
reduced commmiication overhead, and greater productivitv*. 

Based on the DDG-51 program data, some integrated design and analysis was available in concept design. 
However, this was less apparent in preliminarv' design and beyond. As such, the current model considers the efforts 
of hull engineering as separate disciplines. Future v anations of the design process model, may reflect the integrated 
environment through a merging of design disciplines. However, design tasking will not entirely merge as detailed 
design tasks (such as structxuul engineering and arrangements) are still specialized disciplines requiring separate 


J. Evans, “Basic Design Concepts”, Naval Engineers Journal , November 1959. 
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design actions. For instance, Newport News Shipbuilding uses an integrated software environment (VIVID s\stem 
using a 3D product model) in detailed design.Altliough the system provides a common interface and model 
information is fully accessible to all designers, the design team still requires separate structural designers, weight 
engineers, arrangement speciahsts, etc... to perform specific design tasks, and discuss design and analysis results in 
a team enviromnent. 

The task and productivity hull design levels for the baseline case (DDG-51 program) arc provided in Chapter 
8.5. The justification for the DSM is provided below . 

4.6.1 Hull Geometry 

Hull geometry is the cornerstone of hull engineering. Hull geometry’, or the ship’s lines, must meet precise 
and unambiguous” design constraints... and will “consist of orthographic projections of the intersections of the hull 
form vvitli tlirce mutually perpendicular sets of planes.”^As simple as tliat may sound, the process is quite 
complex. The selection of specific hull parameters (length, beam, draft), hull coefficients (prismatic, waterplanc, 
block, midship section), and fairing of hull lines requires iteration and trade-off. To facilitate early design, 
paranietrics and established design lanes are often utilized to estimate hull size and shape.These parameters 
tvpically require estimates of weights, w eight distribution and desired hull speed as inputs. The parameters are then 
iterated for convergence against requirements. More adv anced hull geometrv’ algoritlims, such as the HULGEN 
program in ASSET, combme parametric selections for baseline sizing with a parent hull design to fair intermediate 
station values to tlie hull parameters and coefficients. Tliese methods prov ide a consistent basis for concept trade¬ 
off and perturbations. However, critics point out that use of design lanes constrain innov ation. 

At the preliminary design stage, hull geometry’ uses 3-D graphical modeling and scale model construction. 

As with performance assessment (Chapter 4.5.4), hull geometrv^ design matured greatly with the introduction of 
modeling programs like Hull Form Definition System (HFDS) with its integrated generation and manipulation 
modules (FastShip, FASTGEN, and IA/DS.)^“^ Tliese programs provide increased ability to both generate and 
optimize hull foniis relative to resistance, particularly for monohull designs. Other hull performance analysis, like 
seakeeping and stability’, is also facilitated by common, digital, hull geometry’ definitions. Unusual huUforms, such 
as multi-hull designs or llie wave pieremg bow, must still be physically modeled and tested. Such testing not only 
supports the current design, but provides calibrating data for fiiture computer modeling. 

In addition to the basic hull geometry, other hull characteristics may be selected and modeled to enhance 
performance. For instance, bow (like the bulbous bow) and stem configurations are optimized to reduce resistance 
while maintaining adequate seakeeping cliaractenstics. 


Scott Ripley, Interview at Newport News Shipbuilding, Newport, VA, August 29, 1997. 

Normal Han lin, “Ship Geometry’”, Principles of Naval Architecture, Society of Naval Architects and Marine 
Engineers, Jersey City’, NJ, 1988, Volume I page I. 

Gale and Scott, '*Earlv Stage Ship Design Seminar”, Societv’ of Naval Architects and Marine Engineers, Jersey 
City’, NJ, 1988. 

Whatmore and Wintersteen, A Review of Extant Design Tool Capabilities to Identity’ Common Design Tools for 
Future Collaboration, Naval Surface Warfare Center Carderock Division, Bethesda, MD, 1997, page 20. 
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Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Principle Dimensions 

1 

1 

1 

1 

1 

1 

1 

Parent Ship Properties 

1 

1 

1 

1 

1 

1 

1 

Hullform 

1 

1 

1 

1 

1 

1 

1 

Lines Drawings 

1 

1 

1 

1 

1 

1 

1 

3-D Model 


1 

1 

1 

1 

1 

1 

Curves of Form 


1 

1 

1 

1 

1 

1 

Hull Design Specifications Input 


1 

1 

1 

1 

1 

1 

Hull Design History Input 


1 

1 

1 

1 

1 

1 

Model Test Plan and Model Construction Plan 


1 

1 

1 

1 

1 

1 

Stern Reconfiguration 



1 

1 

1 

1 

1 


Table 23 Hull Geometn’ Tasks 

Table 23 shows the progression of hull geometr\^ tasks in the design process. As discussed above, initial 
tasks are parametrically generated The inputs includes weights, mechanical and combat s> stems, and requirements 
(speed resistance, stabihty). Hull geometry^ represents a field of pure design. In other words, hull geometiy^ is the 
definition of ship characteristics without explicit performance analysis (hull performance analysis is addressed as 
separate disciplines.) 

Generally, all disciplines may be categorized as pure design, pure analysis (a discipline that describes tlie 
perfonnance of a design characteristic, but does not necessanly have the capability or authority to modify' that 
characteristic) or some combination of design and analysis. As a pure design discipline, hull geometry' must provide 
hull engineering input to analysis disciplines wliich include: weight engineering, hydrodvnamics, structures, marine 
engineenng, cost andprograimnatics. 

4.6.2 Weight Engineering 

Weight engineering is a discipline of assessment and design. Weight engineering estimates distribute and 
account for mass distributions in the ship. In early design iterations, these distributions may be purely empirical 
with only a few mass locations (such as engines or combat systems) explicitly known. As the design matures, 
weight engineering relies increasingly on known arrangements, structural specifications, machinery integration and 
combat s>’stems integration for specific placement of weiglits and their locations. These tasks are considered weiglit 
accounting. Anotlier task is hydrostatic definition of the hull. Using the defined hull geometiy^ and internal 
subdivision (arrangements), weight engineers generate bonjean curv'es. floodable lengtii curves, and other 
hydrostatic displacement tools. Given mass-moment and hydrostatic properties, static stability (stability for specific 
angles of heel) is assessed. The analysis w ill include both intact and damaged conditions. 
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Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Deck Height Reduction Study 

1 

1 

1 

1 

1 

1 

1 

Machinery Space Tightness Study 

1 

1 

1 

1 

1 

1 

1 

Tank Arrangements 

1 

1 

1 

1 

1 

1 

1 

Bonjean Curves 

1 

1 

1 

1 

1 

1 

1 

Stability Assessment 

1 

1 

1 

1 

1 

1 

1 

Weight & Mass Properties Analysis 

1 

1 

1 

1 

1 

1 

1 

'‘ability Specifiation Input 


1 

1 

1 

1 

1 

1 

Stai;;’.'ty Design History Input 


1 

1 

1 

1 

1 

1 

Weight (3-. 5-Digit & Contract Weights/Centersj Estimates 


1 

1 

1 

1 

1 

1 

Contract Design Weight Estimates 


1 

1 

1 

1 

1 

1 

Weight Control Program Reports 


1 

1 

1 

1 

1 

1 

Weight Specifications Input 


1 

1 

1 

1 

1 

1 

Weight Design History Inputs 


1 

1 

1 

1 

1 

1 

Construction Margin Report 


1 

1 

1 

1 

1 

1 

Weight Database (to initialize design) 


1 

1 

1 

1 

1 

1 

Margin Allocations 


1 

1 

1 

1 

1 

1 

Floadable Length 


1 

1 

1 

1 

1 

1 

Intact and Damaged Stability Analysis 


1 

1 

1 

1 

1 

1 

Volume and Displacement 


1 

1 

1 

1 

1 

1 

Master Weight Files and Data Sheets 



1 

1 

1 

1 

1 


Table 24 Weight Engineering Tasks 

Table 24 shows the progression of weight engineering tasks. These tasks are dominated b\' accounting and 
analysis. As such, weight engineering requires input from all design specific disciplines as well as requirements. 
Output goes to hydrodynamics (seakeeping requires rigliting moment data) and provides first order analysis to 
structures (for weight distribution ciuves), arrangements, and systems selections (i.e. weight critical loads may need 
to be mov ed or reduced.) 

4.6.3 Hydrodynamics-Resistance and Powering 

Resistance and powering anal>^es the link between requirements, hull geometry , appendage design, and 
propulsion plant selection. For early design, resistance is empirically based (Taylor Standard Series resistance.) 
Later design analysis includes model testing and numerical methods (computational fluid dvnamics (CFD) models.) 


As discussed previously (see Chapter 4.6.2), tlic analysis methods for hydrodynamics are increasingly integrated 
with design tools to provide improv ed design iteration. 


Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Powering/Resistance Charactistencs 

1 

1 

1 

1 

1 

1 

1 

Speed-Power Requirements and Report 

1 

1 

1 

1 

1 

1 

1 


Table 25 Hydrodynamics-Resistance and Powering Tasks 
Table 25 shows the two primary^ resistance analysis task tvpes (resistance determination and report of results 
relative to requirements.) Input requirements include all factors effecting resistance and speed calculations 
(hullform, appendages, powering.) For the current naval ship design process model, output includes hull geometiy*. 
requirements, appendage design and propulsion plant design. Future model considerations merge many of the 
design and analysis tasks in an integrated design environment. 

4/3.4 Hydrodynamics-Seakeeping 

Seakeeping is tlie measure of mission performance of the hullform, and, subsequently, all ship sv stems. 
which considers ship motion in the operational environment. Like resistance, it represents a pure analysis discipline 
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that is being increasingly integrated in a design environment. For instance, the current generation of HFDS provides 
both geometiy^ manipulation and seakeeping analysis with programs including: Ship’s Motion Program (SMP), 

SWMP and SWISP modules for SWATH hullforms, and Seakeeping Evaluation Program (SEP). In past programs, 
seakeeping was rarely addressed in early design. Tliis fact is apparent in the tasking from Table 26. However, 
seakeeping is increasingly important in early design today due to demanding mission requirements. These 
requirements include a greater range of operating environments and greater seakeeping demands to support fliglit 
operations, crew and payload performance. 


Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Seaway Seakeeping Performance Assessment 

1 

1 

1 

1 

1 

1 

1 

Seakeeping Report 



1 

1 

1 

1 

1 


Table 26 Hydrodynamics-Seakeeping Tasks 

Seakeeping requires inputs from requirements, hullform, appendages and weiglit properties, as well as 
auxiliar>' systems (active stabilization). (Outputs from seakeeping go to programmatics, hull geometry and 
appendage sizing. A very^ important output is provided to structural analysis. Structural analysis uses dynamic sea 
loads to de\ elop the structural design for tlie hull. 

4.6.5 Hydrodynamics-Maneuvering, Control and Appendages 

Maneuvering, control and appendages are the remaining sy'stem considerations relating to the hull-w ater 
interface. “(M^euvering) includes starting, steering a steady course, turning, slowing, stopping, backing... 

Tliese tasks include the design and assessment of appendages including rudders, propellers, and passive stabilizers. 
Specific tasks are shown in Table 27 below. These tasks are determined in a manner similar to all previous design 


disciplines. Additionally, tlie tasks are supplemented by the an excellent summaiy^ and description of the component 
tasks found in Table 22 of Principles of Naval Architecture . 


Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Propeller Design Report and Diagrams 

1 

1 

1 

1 

1 

1 

1 

Controllability Assessment 

1 

1 

1 

1 

1 

1 

1 

Propeller Trade-Off Study 


1 

1 

1 

1 

1 

1 

Propeller Specification Input 


1 

1 

1 

1 

1 

1 

Propeller Design History input 


1 

1 

1 

1 

1 

1 

Control and Manuevenng System Design 


1 

1 

1 

1 

1 

1 

Hull Equipment & Appendage Design 


1 

1 

1 

1 

1 

1 

Maneuvering and Propeller Soecificatjoh Inputs 


1 

1 

1 

1 

1 

1 

Maneuvering and Propeller Design History Inputs 


1 

1 

1 

1 

1 

1 

Hydro Performance Assessment 


1 

1 

1 

1 

1 

1 

Steering Gear 


1 

1 

1 

1 

1 

1 


Table 27 Hydrodynamics-Maneuvering, Control and Appendages Tasks 
Data interfaces for maneuvering and control include inputs from requirements, hullfonn, weight distributions 
(for turning moments), propulsion plant configuration (for propeller sizing) and aaxiliary^ systems (for active control 
systems.) Output goes to programmatics and performance, producibility (for integration of appendages), hull 

Crane, Eda. Landsburg, ‘‘Controllability ", Principles of Naval Architecture . Society^ of Naval Architects and 
Marine Engineers, Jersey City, NJ, 1988, cliapter IX. 

Ibid. 
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gcometn^ and weights (for design to performance iterations) and mechanical s> stems (for adequate sizing of 
maneuvering auxiliaries.) 

Note that propeller design is included with maneuvering design. It is equally acceptable to include those 
tasks under propulsion engineering. 

4.6.6 Structural Engineering 

Structural engineering requires the design of hull and deckhouse structure to resist static and dviiamic loads 
on the hull. Additionally, structural engineering provides for support and isolation of instal’od equipment by means 
of foundations and force absorbers. Structural engineering requires inputs from mission requirements and assessed 
performance, hull configuration and loading, and installed equipment and systems. Structural engineering is a 
combined design and analysis discipline. Early structural design uses parametric weight distributions and historical 
wave characteristics, generates anticipated longitudinal bending stresses from these characteristics, and iterates tliis 
process to define a midship section. As the design matures, sections are generated for multiple locations in the hull. 
In areas of higher risk (such as dvmamic loading of radars on masts), finite element analysis (FEA) may be used. 
Later in the process, critical spaces (macliinery^ box, magazines, etc) and e\’entually tlie entire ship are modeled in 
FEA. During detailed design, structural engineering is a prime focus for hull design as the complete hull geometry 
is translated into structural components and details. Specific implementation of structural design is found in 
Hughes^ and Paulling^^^. Structural output is used by programmatics and performance assessment, hull geometty 


and weights, and arrangements. 


Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Define Midship Section Structure 

1 

1 

1 

1 

1 

1 

1 

Longitudinal Strength Assessment 

1 

1 

1 

1 

1 

1 

1 

Payload Structural Assessment 

1 

1 

1 

1 

1 

1 

1 

Shipyard Producibility Practices 

1 

1 

1 

1 

1 

1 

1 

Frame Spacing 

1 

1 

1 

1 

1 

1 

1 

Structural Assessment 

1 

1 

1 

1 

1 

1 

1 

Noise & Vibration Analysis 

1 

1 

1 

1 

1 

1 

1 

Design Criteria 


1 

1 

1 

1 

1 

1 

Structural Specfication Input 


1 

1 

1 

1 

1 

1 

Calculation Report 


1 

1 

1 

1 

1 

1 

Structural Arrangement 


1 

1 

1 

1 

1 

1 

Deck Structural Drawings 


1 

1 

1 

1 

1 

1 

Structural (Scantling) Drawings 


1 

1 

1 

1 

1 

1 

Superstructure/Deckhouse Structural Drawings 


1 

1 

1 

1 

1 

1 

Foundation Design & Weight Effective Foundations 


1 

1 

1 

1 

1 

1 

Structural Design History Input 



1 

1 

1 

1 

1 

Bulkhead Structural Drawings 



1 

1 

1 

1 

1 

PSDM 



1 

1 

1 

1 

1 


Table 28 Structural Engineering Tasks 

Table 28 shows the progression of structural design tasks. Note from Chapter 8.5 tliat over the course of the 
process structural productivity must increase dramatically (by a factor of 200%) to accommodate the substantial 
increase in structural design effort required for detailed design. 


Hughes, Ship Structural Design . Society of Na\ al Architects and Marine Engineers, Jersey Cit\\ NJ, 1988. 
Paulling, “Strength of Ships”, Principles of Naval Architecture . Society of Naval Architects and Manne 
Engineers, Jersey City, NJ, 1988, chapter IV. 
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4.6.7 Space and Arrangements 


Space and arrangements are the means by which the hull volume is allocated and optimized In pre-detailed 
design, general arrangements identify the location, physical boundaries and function of each space in the ship. 

These locations are utilized for weight engineering, survivabilify' assessment (redundancy, separation and 
permeabilify). and manning accommodations. In detailed design, the concern is the development of arrangements of 
equipment within each space with provision for required access to eveiy' component on the ship. Specifically, the 
location of equipment must be selected to satisfy’ individual component performance (location of radar transmitters 
to minimize wave guide runs), component s\’stem performance (redundant fire pumps separated for survivability) 
and total svstem performance (zonal distribution and Collective Protective System (CPS) location.) 

The outputs from arrangements are a significant input to programmatics and specifications. In particular, 
arrangement drawings and Master Equipment Lists (MEL) are an important component of configuration baseline 
designs that complete a design iteration As a design element, arrangements are utilized by performance assessment 
and weights for analysis. Additionally, hull arrangements must converge with macliineiy’ and combat sv stems 
arrangements. (Note that machineiy^ systems and combat s> stems integration include specific arrangement tasks due 
to the unique requirements of those disciplines.) 

Table 29 shows the progression of space and arrangements design tasks. Note that like most other hull 
engineering disciplines, initial tasks are based on parametric or empirical design, and later phases rely on physical 


placement of components. 


Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Arrangements 

1 

1 

1 

1 

1 

1 

1 

Compartment & Access (C&A) List & Oufit Drawings 

1 

1 

1 

1 

1 

1 

1 

Area Requirements 

1 

1 

1 

1 

1 

1 

1 

Volume Requirments 

1 

1 

1 

1 

1 

1 

1 

HVAC, CPS and Zonal System Arrangements 

1 

1 

1 

1 

1 

1 

1 

Specification Control Drawings (SCD) and Specification Inputs 


1 

1 

1 

1 

1 

1 

2D/3D CAD Model Extraction 


1 

1 

1 

1 

1 

1 

Outfitting Trade-Off Studies 


1 

1 

1 

1 

1 

1 

Office Space Arrangement Drawigns 


1 

1 

1 

1 

1 

1 

Medical Arrangements Drawings 


1 

1 

1 

1 

1 

1 

Outfitting Specifications Inputs 


1 

1 

1 

1 

1 

1 

Outfitting Design History Inputs 


1 

1 

1 

1 

1 

1 

General Arrangement Drawings 


1 

1 

1 

1 

1 

1 

Habitability Drawings 


1 

1 

1 

1 

1 

1 

CPS/Zonal Distribution System Drawings 


1 

1 

1 

1 

1 

1 

Design History Input 


1 

1 

1 

1 

1 

1 

Functioinai Drawings - Series "K" 




1 

1 

1 

1 

Fabrication Drawings - Series "F" 






1 

1 

Installation Drawings - Series "1" 






1 

1 

Closure List 






1 

1 


Tabic 29 Space and Arrangements Tasks 

4,7 Machinery Systems Engineering 

Machinery' systems engineering, or marine engineering, is the selection and integration of propulsion, 
electrical and support sv stems. Historically, the boundary’ between machinery’ engineering and hull engineering is 
indistinct. For instance, propeller design is equally important to both disciplines Likcv\ise, the hull form 
determines the propulsion power required to achiev c sustained speed levels and the selected propulsion plant 
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determines the necessary hull form to support the plant. These interdependencies are reflected in the DSM for na\ al 
ship design. Detailed examples of machinery tasks and interdependencies can be found in Harrington^ 

Machinery engineering is an interdisciplinary task set that draws on engineering disciplines ranging from 
mechanical to electrical to chemical to civil engineering. Specific components of machinery design include: 

• Propulsion and transmission s>^stems 

• Electrical generation and distribution 

• Environmental, fluid and support auxiliar>’ systems 

• Non-combat related auxiliary systems (deck, handling and aviation machinery) 

In addition to component selection and design, the machinery plant must be integrated into the total ship and 
consider the total impact of machinery systems on fuel capacity, stack length, and net component accounting 
(weight, space and specification). Machineiy^ system discipline productivity and task levels are provided in Chapter 
8.5. 

4.7.1 Machinery Systems Design and Integration 

Macliinery system design is the integration of subordinate mechanical systems in the ship design. For early 
design phases, this integration provides determination of total fuel requirements (endurance fuel and electrical 
generation fuel) and maclimery arrangements. Preliminary' machineiy' stack length and plant sizing is parametrically 
linked to ship dimensions (length, beam, hull depth). As such, ship geometry is a key input to system design. 
Additional inputs include requirements, perfonnance assessment, weights and arrangements (hull and topside), hull 
performance (resistance), and cost. In later design stages, machinery systems become better defined with specific 
components selected via designation in the Master Equipment List (MEL) and other parts lists. System diagrams 
(cableways, piping, etc) are developed and refined in coordination with general arrangements. Machinery control 
systems are developed for the selected mechanical sy stems. 

The output from systems design must match general and topside arrangements, weight accounts, performance 
estimates and programmatic requirements. Table 30 lists the progression of system tasks. Note that throughout 
mechanical sy stems design, there is little mention of mechanical sy stems development. Rather, it is assumed that 
the chosen sy stems are mature and available w hen required for design mtegration. FuUire iterations of the design 
model may consider specific development schedules for high risk technologies (such as RACER for DDG-51 or 
Integrated Propulsion System (IPS) for DD-21) and represent those dynamics endogenously. 
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Roy Harrington. Marine Engineering , Society of Naval Architects and Marine Engineers, Jersey City, NJ, 1992, 
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Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Fuel Requirements 

1 

1 

1 

1 

1 

1 

1 

Ship System Development 

1 

1 

1 

1 

1 

1 

1 

Machinery Arrangement 

1 

1 

1 

1 

1 

1 

1 

Master Equipment List (MEL) 


1 

1 

1 

1 

1 

1 

SSES & LBEF & SSEB Support 


f 

1 

1 

1 

1 

1 

Machinery Developments Studies 


1 

1 

1 

1 

1 

1 

Machinery Controls 


1 

1 

1 

1 

1 

1 

Machinery Control Arrangements 


1 

1 

1 

1 

1 

1 

Outfit and Furshining 



1 

1 

1 

1 

1 

Material Design Standards 




1 

1 

1 

1 

System Diagrams with associated parts list 




1 

1 

1 

1 

Interference Checking 





1 

1 

1 


Table 30 Machinery Systems Design and Integration 

4.7.2 Propulsion Systems 

Propulsion s\'siems engineering is the selection and design of the components of the propulsion train. As 
discussed previously, these efforts do not require the specific development of a propulsion engine (such as a specific 
gas turbine or diesel engine). Rather, they provide for the selection of engines, determination of required ship 
support for tlie engines and development of power train elements for transmission of power. It is possible that 
selected engine s\ stems may not be mature during the initial design phases. This is particularly true during the 
development of nuclear power sv'stems or new technologies (such as IPS.) For the purposes of the current model, 
these issues are ignored. However, such issues can have a significant c>'cle time impact on design. Aside from 
pnme mo\ ers, many unique components such as reduction gear, shafting and clutches, may be specifically designed 
within the context of the naval engineering process. Table 31 describes many of the specific pow cr sv stem decisions 
that must be made during this tasking. 


Number of propulsors/shafts 

Direction of shaft rotation 

Number of engine rooms 

Number/T\pc of prime movers 

Gear T>pe/Location 

Exhaust energv' usage 

Power transmission method 

Fuel T\pe 

Pow er plant location/geometrv' 

Power plant mounting 

K factors 

Gear Configurations 

Regeneration 

Thrust reversing method 

Control t\pe 

Inlet type 

Exhaust t>pe 

Deicing metliod 

Power plant locations 

Airborne noise control 

Vibration control 


Table 31 Key Propulsion System Trade-Off Parameters'^' 


In concept design, propulsion plant engineering is tvpically restricted to selection of a powering concept and 
determination of adequacy of the concept to meet performance requirements. As such, inputs must include 
perfonnance, hull resistance, propulsor concepts, hull arrangements and propulsion support svstems. Note that 
propulsor design is included with maneuvering and control. It would be equally acceptable to include propulsor 
design with the propulsion train instead. 


M\Ton Ricketts, Manual for Naval Surface Ship Design Technical Practices , Naval Sea Systems Command, 
Washington DC, 1980. 
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As machinery space, weight requirements, and fuel needs are generated the output is iterated against 
performance, maintenance and mamiing concepts, weiglits and hull arrangements, support s\stems and cost. Later 
iterations of the propulsion plant further refines these outputs and examines transmission concepts, \ibration. stack 
design, and fluid s> stems. Final design stages require specific arrangements of propulsion components and support 
systems and management of production preparations (parts and components ordering.) The complete progression of 


propulsion sy stem tasking is found in Table 32. 


Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 1 Zonal 

Production 

Mam Propulsion Concept 

1 

1 

1 

1 

1 

1 

1 

Main Engine Selection 

1 

1 

1 

1 

1 

1 

1 

Propulsion System Trade-Off Study 


1 

1 

1 

1 

1 

1 

Fluid System Diagrams 


1 

1 

1 

1 

1 

1 

Endurance Fuel Requirements 


1 

1 

1 

1 

1 

1 

Propulsion System Design Report Input 


1 

1 

1 

1 

1 

1 

Propulsion System Specification Input 


1 

1 

1 

1 

1 

1 

Shafting Drawing 


1 

1 

1 

1 

1 

1 

Shafting Vibration Analysis 


1 

1 

1 

1 

1 

1 

Propulsion System Design History Input 



1 

1 

1 

1 

1 

Stack Gas Flow 



1 

1 

1 

1 

1 


Table 32 Propulsion Systems Tasks 


4.7.3 Electrical Systems 

Electrical systems design follows a similar progression as propulsion plant design. During early design 
stages, an electrical sy stem concept is developed to accommodate performance requirements, support systems and 
combat systems. Electneal requirements are initially sized based on manpower levels, hull parameters and known 
power requirements for selected shipboard systems. Later design stages examine electrical load demand and 
distribution. Management and accounting of electrical capacity' and demand becomes increasingly important later in 
design as sy stem growth naturally occurs. 

Electrical system growth is substantial over time. The first naval \ esscl equipped with electrical pow er (the 
cruiser USS TRENTON in 1883) had 13.2 kW of power capacity. In contrast the DD 963 destroyer (1970 s) has 
6000 kW capacity' and tlie DDG-51 (1980's) has 7500 kW. This growth in electric requirements is attributed to the 
following technological developments^^": 

• Weapons dc\'elopment including ammunition handling and electronic warfare sy stems 

• Electronic command, control, and navigation sy stems with higli powered radar, sonar, and electronic data 
processing equipment 

• Habitability improvements including electric heating, air conditioning, illumination, and refrigerated storage 

• Increased use of electric and electrohydraulic auxiliary systems 

These trends require some increases in electrical design effort. However, the greatest trend impacting effort is the 
inclusion of Integrated Power Systems (IPS.) With the design of an '‘all-electric'’ ship, this category' of design could 
experience significant growth. 

For the current model, DDG-51 efforts are modeled with the task progression shown in Table 33. 


Ibid., page 10-8. 
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Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Electric Distribution Design 

1 

1 

1 

1 

1 

1 

1 

Electric Plant Concept 

1 

1 

1 

1 

1 

1 

1 

Electrical Line Diagram 


1 

1 

1 

1 

1 

1 

Lighting Analysis 


1 

1 

1 

1 

1 

1 

Electrical System Specification Input 


1 

1 

1 

1 

1 

1 

Electrical System Trade-Off Study 


1 

1 

1 

1 

1 

1 

Electrical Load Analysis 


1 

1 

1 

1 

1 

1 

Electrical System Design History input 



1 

1 

1 

1 

1 


Table 33 Electrical Systems Tasks 

4.7.4 Auxiliary and Support Systems 

Aaxiliaty systems design includes those system required to support ship s>'stems. Specifically, SWBS group 
500 items dominate this category of design. Auxiliary’ systems are selected based on inputs from requirements and 
performance, manning, hull geometry (utilized for concept level sizing), control sy stems, available weight and 
space, propulsion and electrical systems, and combat systems. The selected systems provide capabilities for: 

• Damage Control.. .ventilation, dewatering, sensing. CPS 

• Environmental Control... heating, v entilatioa air conditioning, refrigeration 

• Fluid Management... sea water supply, fresh water generation and distribution, air/gas supply 

• Pollution Control... oily waste systems, sewage treatment, solid waste disposal, chemical/toxic waste 
disposal 

As a closed loop design process, output selections are provided to input categories and costing for comparison and 
iteration. With the introduction of increased computmg capacity^ aboard modem warships, this category' may grow 


to provide adequate environmental conditioning. For the baseline case, tasking is established per Table 34. 


Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Distributive System and Auxiliaries Design 

1 

1 

1 

1 

1 

1 

1 

Fluid System Trade-Off Studies 


1 

1 

1 

1 

1 

1 

Fluid System Arrangement Diagrams 


1 

1 

1 

1 

1 

1 

Fluid System Design Hi^orv Input 


1 

1 

1 

1 

1 

1 

Fluid System Specifications Input 


1 

1 

1 

1 

1 

1 

HVAC Trade-Off Studies 


1 

1 

1 

1 

1 

1 

HVAC Diagrams and Arrangement Drawings 


1 

1 

1 

1 

1 

1 

Fart Room Arrnagements 


1 

1 

1 

1 

1 

1 

HVAC Design History Input 


1 

1 

1 

1 

1 

1 

HVAC System Report 


1 

1 

1 

1 

1 

1 

HVAC Specificaton Input 


1 

1 

1 

1 

1 

1 

HVAC System Requirements and Criteria 



1 

1 

1 

1 

1 

Steering Systems 



1 

1 

1 

1 

1 


Table 34 Auxiliary and Support Systems Tasks 

4.7.5 Deck, Handling and Aviation Support Systems 

Tile remaining systems are those components assigned to SWBS groups 570, 580 and 590. Specifically, 
these systems are required to support conventional ship operations (like mooring, anchoring, towing, etc), underway 
replenishment operations (UNREP) and aviation operations. These sy stems are less dependent on input then 
previous mechanical sy stems. Specifically, input is required from performance and requirements, weight and space 
allocations and electrical and support system budgets. Tlie design output is returned to the input disciplines and 
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cost, manning and maintenance. The progression of task elements is prov ided in Table 35. For future design 
models, these tasks will input to topside design because of their importance of reducing ship signatures. 


Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Deck/UNREP Systems 

1 

1 

1 

1 

1 

1 

1 

Deck System Trade-6ff Studies 


1 

1 

1 

1 

1 

1 

Anchor Mooring & Towmg Drawings 


1 

1 

1 

1 

1 

1 

Deck Systems Design History inout 


1 

1 

1 

1 

1 

1 

Deck Systems Specification Input 


1 

1 

1 

1 

1 

1 

Aircraft Support System 


1 

1 

1 

1 

1 

1 

Boat Handling and Stowage Arrangements and Drawings 


1 

1 

1 

1 

1 

1 


Table 35 Deck, Handling and Aviation Support Systems Tasks 

4.8 Mission Systems Engineering 

Mission s>'stems engmeenng, also known as combat sv stems engineering, is the selection and integration of 
those combat payloads necessary to meet the mission requirements of the surface combatant. Tlie selected sy'stems 
must be fully integrated into tlie arrangements of tlie combatant. Recall the combat sy stems trends discussed in 
Chapter 1.1.3 and Figure 12. Older combat sy stems (gun sy stems and visual guidance) were weight critical, dense, 
and placed low in the hull. The resulting ship had large displacement, but smaller beam for the desired stability 
requirements. The combat system provided a reaction time suitable for the threats of that time. As threat 
capabilities advanced, combat sy stems matured vvitli the transition from guns to missiles and visual to radar 
guidance Consequently, the ship integration issues changed. Modem warships must accommodate volume and 
height critical systems to achiev e necessary^ performance. The result was initially lower displacement in ships like 
the DD-963 with less dense, moderately high systems. As response time and multi-mission performance demanded 
increased sensor height and greater payload v olume, displacement and beam growth was necessary^ to provide 
adequate stability for highly placed radar sy^stems. 

Note that combat sy stems engmeering in this context is not the design of combat sy stems themselv es. The 
fields of combat systems design (detect to engage chains) and testing (probability of detect and kill, reliability, etc) 
represent product dev elopment processes unto themselves. Altliough these sy stems are becoming increasing 
integrated into the ship development process (such as the Aegis Weapon System and CG-47), removing weapon 
sy stems development from the boundaries of tlie model is necessary^ to allow examination of naval ship design. 
Future models may endogenously include major weapon systems development. However, tliese sy stems should 
only be included if tlie weapon sy stems dev elopment schedule are shown to dy namically influence tlie ship design 
process. 

Baseline productivity and task levels for the DDG-51 program combat sy stems integration (independent of 
combat systems development) are provided in Chapter 8.5. 

4.8.1 Mission Systems Selection, Design and Integration 

Mission sy stems include those payloads required for tlie combatant to satisfy specific warfare requirements of 
the ORD Tliese sy stems can include commumcatioiis (both internal and external), sensors, weapons and control. It 
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does not include the development process of those systems, but rather assumes systems are available and must be 
integrated with the ship design. Note that there has been tremendous criticism over the years concerning the 
apparent disconnect between the ship design communit}^ and weapon s} stems development community. 

Specifically, lack of coordmation between the two communities has lead to tremendous schedule fluctuations. 
Consider Figure 33. The figure shows the months required to launch each vessel in the class for the CG-47 Aegis 
Cruiser. Note that the class experienced 4 major combat system baseline changes over the course of the program. 
This can be correlated to the four oscillations in delivery schedule. This trend dominates actual hours of effort 
which reflect the expected learning curv e. Thus, schedule delays from late GFE/GFI/GFM effectively negate the 
benefits of production efficiencies. This trend is changing in current programs like DD-21 and should be considered 
in future model designs. 

Input requirements for mission sv stems design include performance and requirements, weight and space 
budgets, support sv stem capacity and topside arrangement issues. Output is iterated with the same disciplines as 
well as structural design and cost. The complete progression of design tasks is shown in Table 36. 
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Figure 33 CG-47 Class Deliverv Schedules and Production Efforts‘^^ 


Tibbitts and Keane, “Naval Slup Design in the 21"^ Century"’, Society of Naval Architects and Marine Engineers, 
Jersey City, NJ, 1993. 

Mike Jeffers, Interview at Naval Surface Warfare Center Carderock Division, Bethesda, MD. November 12, 
1997. 
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Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Combat System Integration Management 

1 

1 

1 

t 

1 

t 

1 

IC/Navtgation Integrabon and Diagrams 

1 

1 

1 

1 

1 

t 

1 

EytenorComms{SPAWAR-NAVELEX) System & Antenna Integration 

1 

1 

1 

1 

1 

1 

1 

Shipboard Data Multiplex System (SDMS) 


1 

1 

1 

1 

t 

1 

Combat Systems Design Support. Testing, IVCS & ISMS 


1 

1 

1 

1 

1 

1 

Command and Control Space Arrangements 


1 

1 

1 

1 

1 

1 

Mission Systems Design History Input 


1 

1 

1 

1 

1 

1 

Mission Systems Specification Input 


1 

1 

1 

1 

1 

1 

Armament and Weapon Systems Integration 


1 

1 

1 

1 

1 

1 

1C Matrix 



1 

1 

1 

1 

1 


Table 36 Mission Systems Selection, Design and Integration Tasks 

4.8.2 Topside Design and Integration 

With the introduction of modem weapon s> stems (missiles, communications, and radars) has come increased 
need to manage topside design. Specifically, modem combat s\'stems generate unique integration problems due to 
azimuthal coverage requirements, electromagnetic interference (EMI), signature reductions including radar cross 
section (RCS) and Infrared (IR), and aperture heiglit requirements. These needs require detailed accounting and 
modeling of sy stem interactions and allocation of valuable topside real estate. At the concept level, integration is 
t>pically linuted to basic arrangement diagrams. The requirements for inputs include mission s\ stems selected, 
distance and capacity of supporting s> stems, arrangements of non-combat system topside elements (deck, handling 
and aviation s> stems), and perfomiance requirements. Of particular concern are the mass moment and subsequent 
stability of the ship. As topside s\ stems demand increasing heights and weights, the impact on hydrostatic 
performance is significant. As discussed previously, these impacts are proving e\ olutionaiy^ in combatant ship 
design. 

In later stages of topside design, specific analysis of EMI impacts, coverage, source-victim effects, and 
combat system performance must be addressed to optimize topside arrangements. Like hull engineering (HFDS), 
the demands of technology coupled w ith tlie current trend to integrate design and analysis has resulted in the 
creation of softw are suites for topside engineering. Systems such as LEAPS and Electromagnetic Engineering 
(EMENG) are pro\ iding topside engineers with the ability to anahze greater combat s> stems detail much earlier in 
the design process. Such efforts are necessaty if modem w arships are to meet current requirement demands for 
passive and active defense. Later variations of the design process model may be modified to reflect the increased 
concept design effort necessary^ for programs like the DD-21. The baseline tasking progression is shown in Table 
37. 


Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Topside and Combat Systems IntegraDon 

1 

1 

1 

1 

1 

1 

1 

Topside & Combat Systems Arrangements 

1 

1 

1 

1 

1 

1 

1 

topside Arrangement Drawings 


1 

1 

1 

1 

1 

1 

EMI Analysis 


1 

1 

1 

1 

t 

1 

Arcs of Fire & BAM Analysis 


1 

1 

1 

1 

1 

1 


Table 37 Topside Design and Integration Tasks 

Output from topside engineering is iterated with mission sy stems selection, support s>'stems. arrangements, 
w eight, perfomiance, maintenance and manning, and progranunatics. 
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4.9 Cost Engineering 


A final component of the total s> stems engineering process, along w ith performance assessment and 
schedule, is cost. In this context, cost represents all aspects of total ownersliip cost (TOC) for the developing 
system. In the context of the naval ship design process, cost engineering represents that component of ship design 
by w hich the acquisition and life cycle cost of the developing design is assessed against program cost constraints. 

As such, it does not include the expenditures of funds for R&D or current spending on the design process (those 
current costs are modeled explicitly, see Chapter 5.5). Cost engineering addresses the specific cost d\namics 
discussed previously in Chapters 1.1.3 and 2.3. These behaviors demonstrate that cost is and will continue to be the 
primarv' driver in naval ship design and acquisition. DDGol cost constraints explicitly operated as a closed loop 
feedback control process... indicative of a dvnamic control process. Exceeding cost estimates resulted in 
significant design effort and design change (see Figure 16.) Tliis trend is severely criticized in liglit of questionable 
cost estimate accuracy. The result is increased demand for robust costing methods such as Product-Oriented Design 
and Construction (PODAC) cost models and access to costing models such as ACEIT at llie engineering lev^el. 

These issues are beyond the scope of this work. However, the impiicts of these methodologies provide more tasks m 
earlv^ design off-set by decreased iterations generated from cost. The result is a relatively constant productivitv' rate 
for costing and decreased feedback late in the design process (after concept design.) 

Chapter 8.5 contains productivitv' and tasking baseline data for the DDG-51 program. Specific tvpes of cost 
estimates and their relationships to tlie design process are prov ided below. 

4.9.1 Cost Estimates and Analysis 

Cost estimates and analysis are the aggregates of all engineering cost studies for the naval ship design 
process. These estimates represent specific tvpes of cost estimates required by DoD doctrine at each milestone and 
consequentially, each design phase. Note that design process budgeting considers a separate process within the 
naval sliip design model. Budgeting for the design is accomplished by the Planning, Programming, and Budgeting 
System (PPBS) and is explicitly modeled (see Chapter 5.5). 

Cost estimates are designated by classes, which correspond to a given phase of the design process. The 
least detailed classes of cost estimates are Class E and F. They are based on 1-digit weight based cost models such 
as parametric cost estimating relationships (CERs). If specific costs for components (propulsion systems or combat 
systems) are known, they are included The ACEIT model uses CERs. Class E and F estimates provide order of 
magnitude estimation for concept design. At the end of concept design, a Class D estimate may be provided. Class 
D estimates provide refined weight based cost and establish the basis for design-to-cost estimates for contracting. 
During prcliminarv' design. Class C estimates are provided. Class C estimates are budget quality estimates, but are 
still based on weight based parametrics. However, these estimates increasingly incorporate engineering analysis of 
design characteristics. For instance, with the introduction of PODAC costing metliods. Class C estimates should 

Hope and Stortz, ‘'Warships and Cost Constraints". Naval Engineers Journal . March 1986, page 41-43. 
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begin to reflect direct producibiliw cost impacts beyond simple shaping functions which are often applied to 
parametrically based costs. Additionally, life cycle cost models are being developed to provide cost analysis of 
manning, ILS, and operational impacts as well as development and production. For example, the ACEIT cost model 
is modified to provide differentiation of varying production rates and multi-year contracts. Class B estimates are 
provided during contract design. These estimates establish the cost ceiling for the acquisition (again by design-to- 
cost methodolog}' and Upically, weiglit based costing models) by which contract bids are judged. Class B estimates 
are often referred to as Bid Evaluation Cost Estimates. Detailed cost estimates, or post-budget costs, are realized 
costs associated with material acquisition and compared to bid and contract cost estimates. 

There is an ever-increasing body of cost estimating tools, cost trade-off studies and cost-risk tasking. For 
modeling purposes, the growth of cost tasking is ignored relative to the baseline program. Baseline tasks (DDG-51) 
are shown below^ in Table 38. Inputs for de\'eloping these tasks are primarily weight based. Therefore, cost tasking 
relies on design characteristics (hull, weights, structures, machineiy^ and combat systems) that are related to SWBS 
groups. For life cycle cost estimates, manning, ILS, and producibility are also incorporated. The output from 
costing is pro\ ided to programmatics as well as first order changes to those design characteristics that exceed cost 
thresholds for cost sensitivity such as structural weight and auxiliary^ systems. 


Task Element 

Concept 

Preliminary 

Contract 

Detailed 

Functional 

Transition 

Zonal 

Production 

Independent Cost Estimate & Unit Cost Report (tCE/UCR) 

1 

1 

1 

1 

1 

1 

1 

Class D/E/F Cost Estimate 

1 

1 

1 

1 

1 

1 

1 

Program Life-Cycle Cost Estimate 

1 

1 

1 

1 

1 

1 

1 

Class C Cost Estimate 


1 

1 

1 

1 

1 

1 

Weight & Cost Engineering 



1 

1 

1 

1 

1 

Class 8 Cost Estimate 



1 

1 

1 

1 

1 


Table 38 Cost Estimates and Analysis Tasks 


Myron Ricketts, Manual for Na\ al Surface Ship Design Tcclmical Practices , Na\ al Sea Systems Command, 
Washington DC, 1980, section 14. 
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5 Process Model Sectors 


The following sections provide brief descriptions of the primaiv^ components of the naval ship design model. 
For specific model elements (equations and values) refer to the Vensim modeling code provided in chapter 8.7. A 
graphic representation of the design process model is shovvii in Figure 35. 

5.1 Process Sector 

The basic structure for all sv steni dvmamics product development models is the rework (or work 
accomplishment) structure. The structure may have several fonns such as that shown in Figure 22 or Figure 34. 

The structure demonstrates that from an initial pool of work to do (TBD), work is accomplished at some rate. Based 
on a dvTiamically determined lev el of quality, some work is accomplished correctly and some requires rework. The 
incorrect tasks remain in error until discovered through a QA process and reassigned as work to do. 



Figure 34 Work Accomplishment Structure 

Several specific project models vv ere examined for applicability to the naval ship design process problem. 
These previously dev eloped models include the Ingalls Litigation Model (Cooper, 1980), Program Management 
Modeling System (PMMS) (Pugli-Roberts Associates, 1997), Software Project Model (Abdcl-Hamid and Madnick. 
1991) and Concurrent Development Model (Ford and Sterman, 1997). Each model was studied for behavior and 
policy elements applicable to naval ship design. Selected components of those models form the structural engine for 
the naval ship process model. Figure 36 show s this structure. 
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Figure 35 Naval Ship Design Process Model 
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Figure 36 Naval Ship Design Process Model Work Accomplishment Structure 


5.1.1 Primary Work Flow 

Tlie stnicture in Figure 36 demonstrates an operational \ iew of the design process. At tlie beginning of the 
current design phase, some known level of baseline tasking is released as tasks to be done (TBD). Those tasks are 
assigned to the engineering staff and become work in progress (WIP). Based on an accomplishment rate (Comp 
Rate) tasks are completed. Tlie completed tasks citlier require iteration (due to internal error discover)' or design 
spiral relationships) or review Tlie re\ lew ed tasks either require iteration (review error discover)) or release as 
approved tasks. Appro\ ed tasks are considered completed and not subject to fiirtlier action. Note that this 
assumption may fail to fully capture rescope impacts wliich occur \’cr)' late (higli levels of appro\'ed tasks) in the 
design pliase. The iterated tasks represent rework and arc accumulated for coordination (Coord Rate). Based on a 
coordination rate, the rework is released back to the work flow as WIP. The structure also reflects the potential for 
scope growth (rescope rate). Rescope tasking enters the flow tlirough TBD for assignment. 

5.1.2 Review and Approval Factors 

A key structure in the process is the inclusion of review and approval. For naval ship design projects, such 
review is required by law. However, the extent and duration is subject to interpretation Review is considered an 
internal activit)' performed at the program level and below. Primar)' participants arc program management staff. 
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activity staff (both NAVSEA and contractors) and interested parties. Approval is the acceptance of the design by 
external forces. Approval must include tliose organizations required to participate by law (DoN, DoD and program 
managers) and interested parties. As discussed in Chapters 1.1 and 4.4, tlie review process is a source of cycle time 
delay and growth. The required products for design review and the large numbers of review and approval levels 
were a primaiy^ concern to DAC study participants. During the DAC, data was gathered that described average 
approval and review periods for over 45 DoN projects. Additionally, limited data on CG-47 and DDG-51 approval 
and review periods was available. These values are shown in Chapter 8.5. Interviews (see Chapter 8.2) with 
process participants indicated that review and approval times (not error correction) are the primarv' sources of 
generated delays. As such, the model incorporates these delays directly as approv al and review periods through first 
order control 

6.1.3 Error Generation and Detection 

Errors form a significant source of feedback in a development process. As discussed in Chapter 3.1, 
generated errors (regardless of a specific cause) must be discov ered and reassigned to correct. In system dynamics 
models, error generation is a dvmamic e\^ent that may be coupled to forces such as schedule pressures, workforce 
experience, and fraction of Job complete. QA efforts are also dviiamic with improved QA productivity occurring as 
the project approaches completion Functional forms for error and QA efforts relative to those forces can be found in 
Abdel-Hamid and Madnick, 1991^^^. 



Figure 37 Naval Ship Design Process Model Error Sector 
Figure 37 shows the error sector for the naval ship design model. Two d>Tiamic modifiers were chosen for 
error generation and discover}. First, errors are more likely in earlier design phases than later. As such, the chosen 

Abdel-Hamid & Madnick, Software Project Dynamics: an Integrated Approach . Prentice Hall, New Jersey. 
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error fractions (as a fraction of total tasks completed) reflects decreasing rates as the project approaches detailed 
design. Additionally, as the total error discovered increases, tlie fraction of new error decreases. In error discover\\ 
these factors work in reverse; as the project matures QA improves and as total errors increase QA effectiveness 
increases. The selection of baseline error rates (20% in concept design to 10% in detailed design) w ere based on 
interviews with personnel at both NAVSEA and Bath Iron Works (BIW) (see Chapter 8.2). 

5.1.4 Design Feedback 

The one structure of the naval ship design model not found in other system chmamics models is that of the 
design feedback loop. This dynamic reflects the interrelationship of the 23 specific design disciplines participating 
concurrently in the design process. Using the DSM developed in Chapter 4.3, tasks are reworked at a rate consistent 
with the following criteria: 

• As task A is completed a fraction of that task is “undone” by concurrent work in tasks to w hich task A is 
dependent 

• Task A is “undone” at a rate not to exceed its own completion rate or 

• “Undone” at the fastest rate of all its input tasks. 

The feedback fraction represents the fraction of tasking that are “undone" by process concurrence. The value may 
be though of as either the average allowable margin for change at tlie given design pliase or as 1 minus the fraction 
of performance and cost lock-in (see Figure 5.) Those tasks that are sent to iteration must be coordinated to 
determine what data has changed and what errors must be corrected. The coordination rate is (like the approval and 
review dynamic) a first order control through TBCoord and the average coordinate period. 

5.2 Scheduling Sector 

5.2.1 Desired Schedule 

The concept of schedule encompasses the desired cycle time for the design project. It represents one of the 
three primary trade-offs of the project (Section 1.1.) It is by the selection of schedule that all other model variables 
are estimated and controlled. For instance, fixing schedules and design products produces a required manning le\ el 
and the subsequent cost of those persomiel. Schedule is not fixed over the life of the project. Consider Table 39. 

The desired schedule for contract award was allow ed to slip many times over tlie course of the DDG-51 project and 
at increasing rates as the estimate date and the desired date converged. Table 40 further demonstrates the sliding of 
schedule dates over the course of the project. 
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Date of Estimate 

March 15, 1983'^*" 

June 1, 1984*^"' 

December 9, 199U"^^ 

Desired Schedule 

December 15, 1984 

January 10, 1985 

April 2, 1985 

Change from Previous Estimate 

— 

1 month 

3 months 


Table 39 Schedule Estimates for DDG-51 Contract Award^**^ 


Date of Estimate 

4/15/83 

6/1/84 

6/1/87 

12/9/91 

Concept Design Start 


8/1/78 



Senior Review 


2/1/82 



Command Review 


12/15/82 



Concept Design End 


3/31/82 



Preliminary Design Start 


3/31/82 



SCIB 


10/1/82 



Senior Review 


12/1/82 



Command Review 


12/15/82 



Preliminary Design End 


5/13/83 



Contract Design Start 


5/14/83 



DSARC 



8/26/83 


Baseline Freeze 



9/2/83 


Invoke Configuration Control 

7/22/83 


9/30/83 


Contract Design Circulation 

12/5/83 

3/28/84 

3/28/84 


Senior Review 

12/15/83 

5/15/84 

5/15/84 


Command Review 

1/15/84 

5/29/84 

5/29/84 


Contract Design Reading Session 

3/5/84 

6/1/84 

6/15/84 


Contract Design Signature 

5/25/84 

6/9/84 

6/29/84 


Contract Design End 


3/1/85 



Contract Award 

12/15/84 

1/1/85 


4/2/85 

Lead Ship Launch 


5/1/88 


9/16/89 

Lead Ship Delivery 


9/1/89 

7/1/89 

4/29/91 


Table 40 Key Program Dates and Schedule Shifts'"*^ 

To model this behavior, the following generic elements are applicable (Figure 38.) From an equilibrium 
condition (schedule gap is zero), assume a perturbation occurs and estimated completion exceeds scheduled date. 
Initially, gap increases, pressure to increase workforce levels increases, workforce increases, accomplishment rate 
increases, project duration decreases, estimated date decreases and gap decreases...a balancing s\stem through 
estimated completion date. Simultaneously, as the estimated date exceeds the desired date, the desired date updates 
to match estimates. The time to change schedule represents the average time required to absorb half the schedule 
gap. As the desired schedule increases, the gap decreases, pressure to increase manpower decreases, manpower 
decreases and, ultimately, tlie estimated date slides further.. .a reinforcing s>'stem through desired completion date. 


CAPT J.J. Fee (USN). US Na\T letter 50C/JJF Serial 5032-042. April 15. 1983. 

Naval Sea Systems Command, Ship Design Project Histories: Volume II 1980-1989 . estimated edit date June 
1984. page 2.8-5. 

Joe Daley. PMS-400B Program Office, Wasliington D.C., correspondence dated December 9, 1991. 

See footnotes 138, 139, 140. 

^^^Ibid. 
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Based on the observ ed sehedule (Table 40), the initial values for the baseline design model are established 
(Table 41.) The adjustment time, as input to an exponential deeay fnnetion, may be approximated as follow: 


Adj ustmentTime= 


TimeToCloseGap 

3 


The Time to Close Gap is the time to observ ed pliase end. Thus, an Adjustment Time of 12 months is eonsistent 
with the observ ed results. 


Time to change 



Figure 38 Generic Schedule Model^^^ 


Design Phase 

Concept 

Preliminarv’ 

Contract 

Lead Ship 

Manufacturing 

Initial Schedule Projection 

(months from start) 

36 

48 

60 

72 

78 


Table 41 DDG-51 Design Process Model Desired Schedule Initial Values 


The generie structure is reflected in the na\ al ship design process model as the schedule sector (Figure 39). 
Like the generic structure, tasks remaining are compared to the available manpower and nominal design rate to 
detenninc a projected completion date. This date is compared to the desired date to generate a gap. Based on the 
gap, adjustments are made to manpower, productivity and o\ ertime (see Figure 35 to observe those feedback links). 

One slight modification is noteworthy. Instead of measuring progress by what remains, nav al ship project 
managers measure progress by what is done. Specifically, the perceived tasks completed is a fimction of completed 
tasks (completed, rev iewed and approv ed). Tlie tasks to be done are then generated by comparing completed tasks 
to the expected total tasks for the current phase: initial tasks times the percent phase complete desired. Percent 


Jim Hines, “Molecules of Structiue Version 1.3", LeapTec and Ventana Svstems. 1997, page 85-86. 
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phase complete desired is the fraction of total tasks that must be completed to allow designers to proceed to the next 
iteration. This alternate structure can be found in other project management models.^'*'* 



Figure 39 Naval Ship Design Process Model Schedule Sector 

5.2.2 Phase, Review and Approval Initiation 

Due to the inclusion of multiple design phases (concept design, preliniinar>' design, contract design, lead ship 
detailed design and manufacturing engineenng design) and multiple stages within a single phase (tasks in progress, 
tasks under review, and tasks under approval), it is necessary to establish a structure to initiate subsequent sequences 
and close previous ones. Tlie phase initiation structiue is shown in Figure 40. Based on the comparison of appro\ ed 
tasks to total tasks for the phase, tlie percentage complete is generated. Tliat percentage is compare to the required 
percentage necessary' to proceed to tlie next phase. Wlien the current phase percentage is satisfied, a Boolean 
operator (Current Phase) is set to 1 for the next phase to start the release of new tasks. Simultaneously, Current 
Pliase is set to 0 for the pliase being completed. This prevents the release of further tasks and resources to the 
completed phase. A parallel structure is present for release of tasks to rev iew (completed tasks become available for 
review) and approv al (reviewed tasks become available for approv al). Hovvev er, unlike the Current Pliase variable, 
approval and review operators do not stop previous segments from continuing. 


Abdel-Hamid & Madnick, Software Project Dynamics: an Integrated Approach , Prentice Hall, New Jersey, 
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Figure 40 Naval Ship Design Process Model Phase Initiation Structure 


5.3 Productivity Sector 

ProductiviU’ is the measure of the effective rate by w liich a\ ailable manpower is able to complete assigned 
tasking. Figure 41 show s an example of a generic producti\ ity calculation. This structure shows how* a nominal 
productivity' level (normal productivity) is influenced by factors such as fatigue, schedule pressure (or schedule gap) 
and work adequacy (or fraction of design change). Productivit>' as shown here is measured as the number of tasks 
completed per person per unit time. 

Producti\it>^ is a \ eiy' difficult quantiK to measure. This is true because observ ed productivit>' represents the 

work rate after the modifications by dynamic influences (fatigue, schedule pressure, etc). As such, nonunal 

productivit> represents a fraction \'eiy' different than that w hich is observed. Consider the naval ship design process 

model productivit)^ functions (Figure 42). Like the generic structure, numerous dynamic influences are included: 

fatigue, organizational size, and schedule gap. Tlie average design rate is included to represent the nominal 

productivity level. This value actually represents tlie observed rate for a given project and is calculated as: 

^ TotalTasksPerDesignDisciplmePerPhase 

AverageDesignRate =-- - ---- 

TotalPersonnelPerDisciplmePerPhase • PhaseDuration 

This rate would represent the value used by program managers to assess progress or model tlie process in 
scheduling programs (CPM/PERT models). For the DDG-51, the average design rates are calculated and shown in 
Chapter 8.5. However for the process model, this rate must be adjusted to reflect the actual baseline rate absent of 
dvnamic influences. The obsened rate is multiplied by an adjustment (Adjust Rate) in tlie naval sliip model to 

provide calibration of the observed rate in order to reflect the nominal rate of productivitv'. 
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Figure 41 Generic Productivity Structure 



Figure 42 Naval Ship Design Process Model Productivity Sector 

With the effective productivity rate established (Net Productivity Rate), it is multiplied by the effective 
persomiel level to provide a completion rate (Comp Rate) by which tlie pool of WIP is completed. Note that the 
Comp Rate has a ceiling rate (maximum rate of completion) provided by the first order feedback tlu'ough WIP and a 
minimum completion time for a single design task. That minimum rate is estimated as 1 month in the model. 

A similar structure is shown for the rate at vvluch tasks in rework (TBCoord) are completed. Additionally, a 
staicture for tlie initial assignment of tasks is provided based on the perceived completion rate for available tasks 
(personnel assigned times net productivity rate of those persomiel) and the desired period of design completion 
(Design Phase Duration). 

Tlie effective personnel available for assigmnent is modified by three inputs. First, the basic manning level 
represents the total number of NAVSEA and contractor persomiel assigned to a particular design pliase and design 
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discipline. Ho\\e\'er. not all men are created equal. Rather, a second modification is necessar>^ to reflect the 
differences in project experience among the personnel. It is assumed tliat altliougli all engineers and designers are 
equally skilled, those who are with the project for more than six montlis are more productive (by an assumed factor 
of 20%) due to experience with the design material and the design organization. Finally, as schedule pressure 
increase, design managers may begin to autliorize o\ ertime work for personnel. As a first order dynamic, overtime 
has the effect of fractionally increasing the personnel level (by as much as 150% for limited durations) without tlie 
need to actually hire new, inexperienced designers. How ever, tlie short tenn impacts of overtime may be negated by 
second order fatigue impacts. 

5.4 Manpower Availability and Assignment Sectors 

5.4.1 Naval Ship Design Organization and Resource Structure 

The Design team is characterized by government and industiy^ participants. Tlie level of participation 
transitions from mostly go\^ernmental to mostly commercial over the course of the program. Figure 43 show s tlie 
increasing fraction of contractor to NAVSEA effort tliat took place o\ er tlie course of the DDG-51 design program. 
In tliis case, the NAVSEA levels were relatively consistent througliout the program, but the participation of 
contractors (both private and other government agencies) increases exponentially during the program. The impacts 
of this transition (shown in Figure 5) are discussed. Such transitions are natural when considering the goal of each 
stage of the process. Tlie organization tliat results from the transitions and iiiainiing levels must reflect by the need 
to manage the design and to assign appropriate resources to design tasks. As presented in Chapter 4. the design 
tasks are natiually broken into design disciplines (23 are listed) Tliese disciplines contain the structure for 
manpower organization and design interfaces. A comparison of design disciplines and mamiing levels is shown in 
Figure 44. 

Consider the organizational charts for the DDG-51 program (Figure 45, Figure 46, Figure 47, Figure 48). 

Each element of the organization represents a portion of the design process structiue captured in the design 
disciplines. For instance, Figiue 45 represents the progranmiatic organization and its linkages to operational 
requirements generation (CNO), engineering resources (NAVELEX, NAVSEA and SYSCOMs), and the design 
itself (Ship Design Manager and Combat Systems Engineer). Tlie Ship Design Manager (SDM) and his/her 
organization is show n in Figure 46. This organization reflects the different task groups (machinery engineering, hull 
engineering, integration and specifications, etc) luider w liich the specific task disciplines are completed. Figure 47 
shows the combat integration and design organization and its linkage to the design througli the program manager 
and SDM. Finally. Figure 48 demonstrates the organization for cost assessment and control. Note the close ties 
between cost and weight necessitated b>- the costing models of that time. For early design stages, the participation 
of shipbuilders is limited as shown in Figure 49. 
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(DDG-61 Contract Design History, Rev June 1987) 



May-79 Ocl-80 Feb-82 Jul-33 Nw-34 Mar-36 


Figure 43 DDG>51 Total Design Effort^"^ 


Data is complied from documentation listed in Chapter 8.4. 
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Figure 44 DDG-51 Manpower Transitions and Design Task Growth'^^ 

As the design transitions to industr>, the organization must likew ise transition. The government design team 
in later stages includes a reduced level of those organizations discussed abo\'e and resident Superv isor of 
Shipbuilding (SUPSHIP) organization that provide contract o^^ersight. The industry participants (coordinated 
through the shipbuilder) include:^"*^ Shipyard Management Teams (Design Management), Functional Design Teams 
(Systems Engineering and Component Integration), Zonal Design Teams (Transitional Design CAD extraction and 
Zonal Design and Manufacturing Design Extraction), and the Materials Management Team. Within detailed design, 
shipbuilders le\'el load teams to maximize resources (teams, designers and engineers, computers) vvlule pro\'iding 
production facihties with design products in a timely fasliion. Detailed design products must be completed Just in 
Time (JIT) to accommodate design changes with minimal impact to completed design products. In other w ords. 
design products are not completed miless manufacturing is ready to proceed. Typical design effort for the DDG- 
51 included in the model consists of a team of 372 engineers and designers w orking in two shifts (244 in first shift, 

113 in the second.) Tlie designers are organized into 8 zonal teams: 3 hull specials teams, 3 machineiy' specialty 
teams, and 2 electronic (combat s}'stems) specialty teams. The teams work eiglit zones concurrently in design and 
no more tlian four zones transitioning to the nex1 subphase at any given time. Teams to provide logistics 


C. R. Lloyd, “Design Process for the AEGIS Destroyer Program”, Presentation, Bath Iron Works D87 Class 
Design Office, November 18, 1997. 

Da\ad Hinds, interview at Bath Iron Works, Brunswick, ME, November 15, 1997. 
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management (ordering and parts management) and design management (ECP management, mformation 
management, etc) are included. 



Figure m. ddg 51 sk!? design command and phogram organization 


Figure 45 DDG-51 Ship Design Command and Program Organization'^’ 


Andy Summers. Contract Design History for the Guided Missile Destroyer (DDG 51 Class) , Na\ al Sea Systems 
Command Washington DC, June 1987. page 2-27. 
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FIGURE 2-2. DDG 51 SHIP DESIGN TEAM OHGA.NIZAnON 


Figure 46 DDG-51 Ship Design Team Organization^^” 
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Ibid, page 2 - 28 . 
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FIGURE 2-3 COMBAT SYSTEM ENGINEERING ORGANIZATION 


Figure 47 DDG-51 Combat System Engineering Organization^""^ 
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Ibid, page 2-29. 
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FIGURE 2-4. RESOURCE CONTROL TEAM ORGANIZATION 


Figure 48 DDG-51 Resource Control Team Organization^^" 


Ibid., page 2-30. 


115 



















































fiBOuKC; 

CCfi'RCL 

ttAY 


DiliLC’iCN 


L^iivANCE 
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Figure 49 DDG-51 System Engineering and Ship Design Team Relationship**^ 


Ibid., page 2-31. 
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5.4.2 Manpower and Adjustments 

The general dynamic behavior of resources is characterized by step increases in manpower from Concept 
tlirough Detailed Design, ascending and declining effort within each phase, and small numbers of governmental 
personnel outsourcing large fractions (50 to 75%) of design effort to contractors. This is captured in the naval ship 
design process model by splitting manpower into two flows: NAVSEA and Contractors. Figiu*e 50 shows this 
structiue. NAVSEA personnel are those personnel that are considered free to the program from a budget stand¬ 
point. However, there are fewer NAVSEA personnel a^'ailable and the first order assignment of personnel is more 
difficult as fewer become aA'ailable. Contractor persoimel flows include all those personnel that require budget 
e.xpenditures to work. They include other government agencies (OGAs) such as tlie Nuat labs, ship design 
contractors such as JJMA or AME, and shipyards such as BIW. As discussed previously (see Cliapter 5.3). the 
flow s explicitly include the maturing of designers over tlie course of tlie project. 



Figure 50 Naval Ship Design Process Model Manpower Sector 
Given the available persoimel, it is necessar}^ to determine the desired number of persomicl to be added or 
remo^ ed from those flows (Figure 51) and the distribution of persoimel requirements between go\ ernment and 
private resources (Figure 52). Several noteworthy properties are demonstrated in these structures. First overtime is 
modeled to reflect tlie means by which managers assess overtime needs (Indicated Overtime Required and the Effect 
of Schedule Gap on Ov ertime) and the impact of overtime for extended periods on productivity (Fatigue). Fatigue is 
a stock because the accumulation of fatigue does build ov er time and takes time to decrease again. Secondly, 
manpower loading levels (seen Figure 43) show decreases in both total effort and percentage of contractors w hen 
approv al stages begin. Table functions for the effect of approval pliase on desired manpower and on NAVSEA 
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fractions are also included. The model detemiines a desired manpower level, adjusted by these effects, and uses tliis 
value to requisition new personnel or release personnel based on a perceived manpower gap (manpower shortage). 
The shortage is distributed by the desired fraction of NAVSEA persoimel to be hired. If persoimel are to be 
released tlie model attempts to release new personnel prior to experienced manpower. This effect is included based 
on inter\’iews with managers from NAVSEA and BIW 



Figure 51 Naval Ship Design Process Model Desired Manpower Sector 



Figure 52 Naval Ship Design Process Model Manpower Allocation Sector 
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5.5 Financial Sector 


The financial sector is the link between the design process model (schedule) and the available design budget. 
This process fits within the context of the formal DoD budgeting process: the Planning, Programming and 
Budgeting System (PPBS). The PPBS is a multi-year budgeting s\^stem that addresses all areas of military^ budget 
including both operational expenditures and acquisition. Program managers must interact with the PPBS to secure 
funding for future design and acquisition costs and continue to justif>^ current expenditures. 

The sy stem consists of three distinct phases. During the Planning Phase, mid term and long range defense 
goals are assessed against perceived threats. This is similar to the chmamics seen in Chapter 2.1. Based on results of 
this analysis, the National Security Council issues the National Mihtary Strategy Document (NMSD). The 
document is issued in July of odd numbered years. Between then and November 30^ of the same year, the 
document is reviewed and re-issued as the Defense Planning Guidance (DPG). The document defines the fiscally 
constrained force structure into which the program manager must attempt to secure a portion of funds. 

The second phase is the Programming Phase. This phase establishes the allocation of funds to the specific 
force elements tliat must be supported. Tliere are eleven force elements which include strategic forces, general 
purpose forces, research and development, etc. The goal of this phase is to establish the optimized mix of 
manpower and equipment required to satisfy the national defense posture. By April of the next year (even year) 
Program Objective Memorandums (POMs) are prepared. The POMs reflect "a detailed expression of proposed 
programs by program element, schedules and funding 6 years into the future, with force levels 3 years beyond 
that.. .Each POM submission is a modification of the approved FVDP (Future Years Defense Program), updated to 
reflect current guidance from OSD (Office of the Secretary of Defense), with 2 fiscal years being added during each 
(POM) cycle.”^^'^ By September, all POM issues are debated and appro\'ed with the Secretary of Defense appro\ing 
these submissions as the basis for the Budget Estimate Submission (BES). Tlie program manager, based on the 
current and future needs of his or her program, seeks to influence the POM submission to gain additional funding for 
the program as necessary. However, the nature of this S} stem means tliat actual funding requests are not realized for 
at least 2 years from submission and possibly 4 years if tlie submission falls at the end of the POM cycle. 

The final phase is Budgeting. From September tlirougli December, tlie BES and POM are assessed for 
categorical allocations to five pnmaiy^ budget categories: RDT&E, Procurement, Operation and Maintenance. 
Military Persomiel and Militaiy' Construction. During tliis period final budget adjustments known as Program 
Budget Decisions (PBDs) are performed to account for cost factors, risks in projections, the timing of related events, 
jointness of requests, and uniformity. Tlie final budget is submitted to tlie President the first Monday after the 3'^'^ of 
January in the next year (odd). The budget is debated and approved for activation the following fiscal year (Clctober 
of the year of submission). 


Defense Systems Management College, Tlie Program Manager's Notebook, Fort Belvoir, VA, June 1993. 
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The obvious delays in the timescale of the PPBS must be accounted for in the development of the naval ship 
design model. Coupled with the target profile for engineering expenditures during the design process, the PPBS 
manifests itself as a funding delay when increased budget needs arise to meet design schedule deadlines. Consider 
tlie topical engineering cost profile for a surface combatant program show n in Figure 53. Based on past cost profiles 
(such as is shown below), the desired schedule and the complexity of the design program (total tasks to complete), 
the program manager must submit a budget request through the PPBS. Funding is not granted in excess of 
perceived needs, so the program manager are constrained to a fixed schedule and budget. However, as process 
dynamics cause the schedule to slide and the engineering cost fluctuate as does manpower loading (Figure 43), 
funding shortfalls can occur. The time required to overcome the shortfalls is equivalent to the duration of the PPBS. 

I 

Engineering Cost Profiles • 



Design Phase Start Date 


Figure 53 DDG-51 Engineering Expenditures'^^ 

Figure 54 shows the chaiamic budgeting and allocation flow for the naval ship design process. The delays 
from the PPBS are modeled as a first order dela}' through Change to Budget and Time to Change Budget. The Time 
to Change Budget is set to 2 years to reflect the average PPBS cycle time. The Funding Period and Fiscal Counter 
model the fiscal allocation of funds to the program. Actual spending becomes a function of total effective 
manpower costs (i.e. total contractors plus o\'ertime). Note tliat the model explicitly capture overhead costs. These 
costs are included in the value of tlie contracting fee ($6597 per engineer per month).'^^ 

Funding shortfalls occur as two dynamics. First, a funding gap is created that is relie\ ed b> first order control 
tlirough Cliange to Budget and subsequent flow through tlie fiscally controlled Program Budget Rate. The second 
effect is the temporaiy' decrease in funding to contractors (i.e. release of contractors) and the increase of NAVSEA 
engineering efforts to compensate. As budget levels rise once more, these trends reverse. Should a funding surplus 
occur, tlie d} naniic is reversed: the budget decreases over time and the program assigns increasing le\'els of 
contractors to consume the surplus. 

Naval Sea Systems Command, Ship Design Project Histories: Volume II 1980-1989 , estimated edit date June 
1984, page 2.8. 

Ibid. FY1996 dollars projected from 1985 engineering cost estimates for contractors. 
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The final element of the model is the explicit modeling of contract t>pes. Within llie contracting 
environment, program managers have the option of awarding new Requests for Proposals (RFPs) or using existing 
contracts through other program offices. There are ad\ antages and disadv antages to each. New awards prov ide the 
manager (PM) with a dedicated contract, tailored to the current program with no overhead costs imposed by external 
authorities. However, the RFP process can take as long as 18 months to establish and begin actual design work. For 
tliis reason the PM may offer to fund an existing contract being managed by a NAVSEA directorate or other 
program office. Such an approach offers rapid access to contractors and design resources. However, the managing 
office imposes an ov erhead charge of 10% or more of the design costs. Additionally, the contract may not be 
tailored to the particular design problem being studied. As sucli, the PM must decide on an appropriate policy for 
allocation of contract tvpes. In tlie model, these allocations are fixed as percentages of contractor assignment. The 
percentages transition to RFPs as the process matures. 



Figure 54 Naval Ship Design Process Model Financial Sector 
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6 Hypothesis Testing, Modeling Results and Conclusions 


6.1 Baseline Model Results 

The desired behavior for the baseline model is to match the levels and dynamics of the DDG-51 program. 
Obtaining specific data for such an effort is difficult. As was noted in the DAC stud>^ program management 
statistics are highly variable in quality and availability, particularly with respect to manpower efforts. Specific 
documents with such information have been published. These include several NAVSEA documents: the DDG>51 
Guided Missile Destroyer Preliminary Design History , the Contract Design History^ for the Guided Missile 
Destroyer (PPG 51 Class) , and the Ship Design Project Histories: Volume f II and III . From these documents, 
manpower and budgetary trends can be extrapolated Figure 55 illustrates the NAVSEA effort for several recent 
design programs. Strategically, NAVSEA has reduced (over time from FFG-7 to CG-47 to DDG-51) the numbers 
of go\ emment personnel assigned to the program. Operationally, the graph demonstrates increasing engineering 
efforts through each design phase with se\'eral d> namic rises midway through each program, declines at the end of a 
phase, and an extended level of decrease at the end of contract design. 



Figure 55 Early Phase NAVSEA Personnel Effort for Surface Combatant Design Programs^^^ 
Figure 43 shows the significant difference in numbers of government and contractor personnel. Tlie 
NAVSEA effort is small compared to that of Other Government Agencies (OGA) and contractors. Generally, the 
trend for each categoty of personnel follows the total trend effort for the program. There are some unusual 
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vanations in contractor and OGA effort. Howe\'er, as each of these t\pes require budget expenditures to acquire. 
The variations represent a choice by the program manager to select one t\pe of contractor over the other. 

Another noteworthy d\Tiamic is the transition between design disciplines over the course of the project. 
Recall the design disciplines and design products discussed in Chapter 4. Consider the trends shown in Figure 56. 
In early stages of design, programmatic interfaces dominate along with a significant effort in s}^stem performance 
assessment. Other engineering efforts provide input to these categories, but the delivered products are substantially 
less. This reflects the early goal of design to determine requirements and needs. As the program matures, 
increasing effort is in high risk design categories such as combat systems and marine s>'stems integration. In the 
final stages of the design process, very specific efforts in component level definition (hull structural drawings, 
arrangements drawings, machineiy^ arrangements, MELs and parts lists) dominate the engineering effort. 



Based on tliese trends and tlie ch namics discussed in Chapters 4 and 5, tlie na\ al ship design process model 
was adjusted to match the baseline beha\’ior of the DDG-51 program. Figure 57 show s the model results for total 
assigned manpow er compared to the DDG-51 program. The model results were calibrated once by adjusting the 
nominal producthity rates (Adjust Rate, see Figure 42) to match project duration to the DDG-51. These results 
demonstrate the effectiveness of the chmamic model to capture the chmamic behavior of a complex process. 
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Data is complied from documentation listed in Chapter 8.4. 
Ibid. 
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Although not all levels are captured precisely, the d>Tiamic events are. Note tlie agreement of the model and data 
from months 35 to 45 and from months 50 to 90. 



Figure 57 Initial Baseline Results from the Naval Ship Design Process Model 
The differences between the model and data may be accounted for in se\ eral ways. First, note that the data 
shows initial manpower levels of over 50 personnel. Tliis is deceiving. The program had actually started concept 
studies as early as 1978, Tlie model starts from 0 persomiel in 1980 (milestone 0 for the program). Another issue 
with the data is that it implies all personnel assigned to tlie project are \\ orking on the project 100% of the month. In 
reality. NAVSEA persomiel and contractors on existing contracts may have \\'orked only a fraction of the time on 
the DDG-51 and the remaining time on other projects. Ajs such, the data o\'erestiniates mamiing levels... particularly 
in early design phases. Finally, the model was only calibrated using a single variable. Given more time and 
resources, the model could be calibrated more accurately using sensitivity analysis of all model constants and 
tlirough further refinements of the model beha\iors. 

These minor issues do not detract from the value of the results. The model does capture the process 
dynamics. This alone is worthwliile as it provides insight into the causes of specific process behaviors. For 
instance, tlie oscillations at month 45 and month 57 correlate to the end of fiscal cycles where funding shortfalls 
occurred. Armed with this prediction, a program manager may be able to negotiate a budget increase to prev^ent 
future oscillations and subsequent schedule shifts. Thus, the model provides useful results and can be used 
effectively to assess specific hvpotheses. 
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6.2 What if CAE/CAD/CAM Are Used? 


The first hypothesis examined with the model is how the application of computer based design tools effects 
the process dynamics, manpower loading and duration. In earlier chapters, some specific dynamic impacts of 
computer aided engineering, design and manufacturing (CAE/CAD/CAM) were addressed. Computer based design 
reduces error rates by allowing automated interference checking and QA of design products. Sev eral shipbuilders 
(BIW, Newport News Shipbuilding) have reported these improvements. However, reduced errors rates hav e not 
come without serious growing pains. At BIW, the use of early \ ersions of CAD resulted in very high false error 
rates, a false error being the designation of an interference or blockage in the CAD model when no such problem 
exists. From 1991 tlirough 1997, the engineenng division used 3 rev isions of the CAD software, with false error 
rates per zone per design review decreasing from an average of 1000 in 1991 to 100 in 1994 to 10 or less in 1997. 
Although these rates reflect exponential improvements, the five years of learning and adjustment were difficult to 

Other organizations hav e claimed substantial reductions in design time with CAD sy^stem usage. The 
Daewoo Shipyard of Korea installed a CAD sy stem to perform structural design. Table 42 shows the trends in 
usage of that sy stem at Daewoo. From the data, it is quite apparent tliat the organization was committed to CAD 
modernization. Tlie number of computers was increased while the number of designers and the design duration 
were reduced. Could these results be realized for the nav al ship design process? 


Item 

‘89 

‘90 

‘92 

‘94 

No. of Workstations 

10 

40 

60 

82 

No. of Designers (No. using Workstations) 

190 

(20) 

156 

(90) 

156 

(110) 

164 

(118) 

Computerized Drawings (%) 

26 

50 

92 

96 

Detailed Design Period (months) 

7.5 

7.0 

6.0 

5.5 


Table 42 Performance Status of Steerbear-Hull Design System at Daewoo Shipbuilding’^® 

Suppose a specific CAE/CAD/CAM sy stem is proposed. Such a sy stem provides an integrated design and 
data management env ironment for the design process. Based on the Daewoo experience, system designers adv ertise 
the following attributes for the sy stem: 

• Error rate is reduced by 50% (computer integration and design automation should reduce errors) 

• Error discovery^ is increased by 50% (CAD software provides explicit interference detection) 

• Experience (learning) time is increased to 6 months'(computer sy stems do require time for training and 
familiarization) 

• Coordination rate is 50% faster (data transfer ranges from instantaneous with a product model to 
improved with email). 

David Hinds, interview at Bath Iron Works, Brunswick, ME, Nov ember 15, 1997. 

Chris Keimison, KCS Users Meeting Minutes, Kockums Computer Systems, Annapolis, MD, October 31, 1997. 
David Hinds, inteniew at Bath Iron Works, Brunswick, ME, Nov ember 15, 1997. 
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Based on these properties, a model run is developed. The results are shown compared to the baseline run in Figure 
58 The result of these changes is a 13 month reduction in the total design process. This is consistent with the 
results seen for Daewoo Shipbuilding. Some dynamics are particularly notew orthy. The concept design process 
does not appear to change. The preliminaiy design process begins slightly earlier, but really takes off over the 
baseline case by month 30. Specifically, the design interactions are improved by faster coordination and reduced 
errors. Thus, more tasks are available for final iteration in prehminary design at an earher point. The contract 
design starts 5 months earlier and detailed design is able to start 8 months earlier. Thus, the apphcation of computer 
design, applied to a few specific variables (error rates, learning and coordination) pro\ides over a one-year cycle 
time reduction. Note, however, tliat the process did not reduce the number of personnel and even increased 
manpower le\’els in early stages. 


Graph for Net Personnel 



Time 

Figure 58 Comparison of Baseline Model to CAE/CAD/CAM Hypothesis 
What if the ad\ eitised improvements are not fully realized? Such a circumstance is consistent w ith the 
implementation difficulties described previously for BIW. Specifically, suppose the error rate from baseline 
methods is only reduced by 25% vice 50%. The model results for this case are shown in Figure 59. The results 
demonstrate that the process duration is not sensitive to a change in error rate. However, the number of personnel 
required to mauitain tliat schedule, particularly in contract and detailed design, is very sensith e with a 12% increase 
in personnel assigned over the project. As a result, manpower costs increase by over $30 million due to the 
unrealized potential of the CAD sy stem. 
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This example indicates the power of system dynamics modeling to analyze schedule risks 
associated with process improvements. 


Graph for Net Personnel Assigned 



Net Personnel Assigned : 25% Error - Manpower 

Net Personnel Assigned : 50% Error Manpower 


Figure 59 Sensitivity of CAE/CAD/CAIVI Hypothesis to Error Rate Improvements 


6.3 What if Concurrent Engineering and IPTs Are Applied 

Concurrent Engineering and IPTs are proposed as methods to improve responsiveness of the design process. 
Previous discussions examined some specific dynamic impacts of concurrent engineering. IPTs, and IPPD. The 
ability of engineers to effectively communicate vvitli one another should reduce tlie number of design iterations 
required for convergence. Additionally, concurrent engineering front loads many design tasks earlier in the process 
such as producibility. 

For this case, suppose process improvements are advertised to provide the following process modifications: 

• Error discover}’ increased by 25% (teaming will provide continuous data exposure to multiple designers 
and disciplines) 

• Coordination rate is 100% slower (due to communication overhead costs) 

• Design feedback is reduced by 50% (teaming provides better know ledge among designers of task 
interaction impacts and comnumication of data trends) 
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• Approval and Review periods are reduced by 50% (teaming can provide interim communication of 
design requirements, attributes and effectiveness throughout llie process rather than during specific 
approval and review periods). 



Figure 60 Comparison of Baseline Model to Concurrent Engineering/IPT Hypothesis 
Applying these process modifications to the model provides results as shown in Figure 60. These results 
show^ a 16 month reduction in tlie total design process Additionally, the net personnel assigned for the entire project 
(integration of the graphs) is decreased by 10% Tliis is an expected benefit from the use of cross-disciplinaiv' 
design teams. Some of the ch namics are particularly interesting. All the design phases occur faster and witli fewer 
persomiel. Tlie faster design penods allow the process to better weather budget transitions by compacting tlie design 
phases (preliminaiv' and contract design) into periods of about 12 months each Tlie preliminaiy design process 
begins slightly earlier, but really takes off over the baseline case by month 30. Finally, the lead ship design occurs 
so much more quickly tliat the manufactunng design is actually delayed (represented by the saddle in the curv e) to 
await the JIT pull from production. Generally, we can conclude tliat tlie application of teaming in design process, as 
applied to a few' specific vanables (error rates, design feedback, approval schedules, and coordination) provides 
almost a one-aiid-a-half-year cvcle time reduction and overall manpower reductions. 

As with the CAE/CAD/CAM example, sensitivitv' analysis provides insight for nsks to program performance. 
In this example, suppose design feedback is only reduced by 40% vice 50%. Such a circumstance would occur if 
design requirements were continually changing such as during the end of the Cold War. The result is a lengthening 

128 


























































































of the design process by 3 months, a 4% increase in manpower costs and an increased requirement for personnel 
during concept design. Again, sensitivity pro\ides the program manager with a tool to assess the expected impacts 
and risks of proposed process improvements. 
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7 


Conclusions and Future Work 


7.1 Conclusions 

Most schedule analysis tools (PERT, CPM, DSM) only provide the ability to capture hard process vanables 
such as design concurrence or phase durations. These operationally and statistically based methods fail to capture 
the dominant dynamic influences (human factors, error propagation and design feedback) that ultimately lead to 
schedule growth. Additionally these methods do not accurately reflect non-linear impacts such as overtime, fatigue, 
schedule pressures and learning curv es (see Chapter 1.1.1). For these reasons, the naval ship design process model 
is necessarv' and useful. System dynamics modeling provides one of the few means to assess process improvements 
that must incorporate not only architectural changes to the process, but the responses of real people to those changes. 
The obvious physical relationships of naval architecture, marine engineering, combat systems engineering and 
systems engineering are explicitly modeled. Cost constraints and policy reactions are captured. These impacts are 
captured in many other sv stem d> namics models as well (see Tan and Bligh, 1998 and Rodrigues and Bowers, 
1995.) However, these models do not capture the issues of multi-functional design, design feedback or program 
policies unique to naval sliip design. For this reason, the inclusion of the DSM structiue in the naval ship design 
process model is necessarv. 

The naval ship design process model (see Chapter 8.7 for the baseline model) contains the necessary' detail to 
capture the dynamics of a ship design program. Specifically, the DDG-51 program behavior is captured (see 
Chapter 6.1). As the DDG-51 program is now almost two decades old, not all baseline variables are appropriate for 
use with current design programs. 

For instance, there is a trend to shift greater lev els of system analysis into concept design and to more fully 
dev elop the concept variants presented for AoA consideration. By this trend, concept design in the 1990’s 
increasingly examines details reserved for preliminarv' design in the 1980’s. To accommodate this trend, model 
variables for initial tasks levels must increase in the concept design phase to reflect the increased design analysis. 
Additionally, the introduction of integrated design environments increases productivity relative to specific design 
tasks. This is reflected m the trends shown previously in Table 42. However, as the level of analysis increases more 
rapidly than productivity, the resultant design rate may actually decrease. Such specific modifications to variables 
are necessary' to assess modem programs with tlie naval ship design model 

Despite the need for changing variables, the generic structure of the nav al ship design model (see Chapter 5) 
is accurate and does reflect the policy and process mechanisms contained in the ship design process. Thus, with 
modifications of variables consistent with current design process trends (see discussions in Chapters 4.4 through 4.9) 
and calibration of those variables, the model is applicable to ship design programs like the DD-21 or C VX. 

Furtlier, the baseline model provides a structure to judge the impacts of potential process improvements and 
tlie risks associated with the assumptions of those improv^ements. As demonstrated in Chapters 6.2 and 6.3, gains in 
cycle time and manpower reduction are sensitive to the assumptions of the proposed improv ements. Program 
managers can test assumptions and design the process organization to optimize schedule perfomiance. Additionally, 
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the program manager can use the model to trade-off cycle time against mission effectiveness and cost as determined 
by their respective analysis methods (see Chapters 1.1.2 and 1.1.3). 

7.2 Future Uses and Work 

The naval ship design process dynamic model has three potential future uses: 

1. Testing of specific management policies and process improvements 

2. Understanding of the behavioral forces at work in a process 

3. Prediction of future trends 

For policy testing, the model provides a means to test and optimize a management plan (such as when to 
allow schedule sliift or what fraction of NAVSEA personnel to inv olve in a project.) However, a note of caution is 
necessaiv. The full use of any model for policy implementation must be contingent on the support of all process 
participants. Specifically, if knowledgeable personnel have not reviewed the model’s structure and behavior, it 
implementation will be flawed (i.e. tlie dvnamics are correct but the model structure is not tangible or operationally 
accurate.) The result would be accurate baseline behavior but inaccurate hypotheses. As such, continuous 
comparison of the model with observ ed results must take place. It is in this manner that the model can provide 
understanding of behavior forces. 

The model can also be studied to reveal behavior forces within the design process. Through constant dialog, 
process participants and modelers can begin to recognize the causes of cycle time growth, the dvmamics of 
undiscovered errors, the effects of personnel changes on the process, and a multitude of other process behaviors. As 
managers change their mental models of the process to reflect more accurately the dynamic impacts of their 
management decisions, process improvements can be better implemented. Additionally, process authorities are 
better armed with tools to address critics and combat constraining externalities. 

Armed w ith accurate models and xmderstanding of those models, process managers can begin to predict and 
gauge the future trends of process improvements. As demonstrated in Chapter 6, initial results for improv ements 
such as IPTs and SBD liave the potential to significantly reduce cycle time. The next step is the calibration of the 
model to a current program (such as DD-21) and monitoring the expected results against obscrv ation. In this 
manner, a program manager has the necessary^ metrics to modify management policies before critical thresholds 
(spiraling cost or schedule growth) are reached. 

Future modeling work to support and implement the above listed uses include: 

1) Discuss the model with program participants. Calibrate and validate critical dynamics such as cost impacts, 
scheduling methods and manpower allocation. 

2) Integrate the model with other dynamic models (McCue, 1997) for analysis across design and production. The 
naval sliip design process model may ultimately be incorporated in a life cycle process analysis. 

3) Develop dynamic models for externalities (arms race dynamic, etc) and incorporate these dynamics 
endogenously to the model. 

4) Refine the model to 

a) improve manpower allocations for task coordmation and QA. 
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b) improve Program Plamung Budgeting System (PPBS) components relathe to cost 

5) Obtain improved baseline. comparati\ e data by 

a) examining additional metrics (other than manpower levels) at concept and prehminary' design to reduce the 
inaccuracies of collected data 

b) examining d> naniic fluctuations of detailed design manpower levels from shipy ards and SUPSHTP offices 

6) Perform dedicated case studies to analyze hypotheses such as 

a) the impact of shifting design transition from government to industry earher in the process 

b) the dynamic impacts of scope growth in an open architectiu'e design 

These model improvements will provide greater fidelity and usefulness of the model for future use in 
assessing the sy stem optimization and dynamics of the naval ship design process. 
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8.3 Glossary and Abbreviations 


3-D Product Model - Captures all of the information needed to desenbe a ship 

AoA - Analysis of Alternatives, an analysis of the costs and operational effectiveness of altcmati\ e material sv stems 
to meet a mission need and tlic associated program for acquinng each alternative. 

ASR - Alternative System Review 

ASR - Acquisition Stratcg>' Report, describes the acquisition approach to include streamlining, sources, competition 
and contract t>pcs throughout the period from begimiing of Phase I. tlirough end of production. An aimcx to 
the IPS. 

Architcctiu'c - A structure tliat shows the elements and tlicir rclationsliip for a set of requirements or a s>’stcm 
concept or both. 

ATC - Affordability through Commonality' Program 

BIW - Bath Iron Works 

CALS-GCO (Continuous Acquisition and Life Cycle Support- Government Concept of Operations): A document. 
Provides the Govenunent Concept of Operations (GCO) for data associated with the SC 21 Program in 
conformance with the basic strategy' of Continuous Acquisition and Life-Cycle Support (CALS). 

CDR - Critical Design Re\iew', re\icw' conducted to determine that the detailed design satisfies performance and 
engineering requirements of the de\'elopmcnt specification; to establish the detailed design compatibihty' 
among the item and other items of equipment, facilities, computer programs, and personnel; assesses 
producibility' and risk areas; and to re\icw' the preliminary' product specifications. 

CDRL - Contract Data Requirements List, Document used to order and require delivery* of data. Tells contractor 
what data to deli\er, when and how it will be accepted, where to look for instructions, etc. 

COEA - Cost and Operational Effectiveness Analysis, OBSOLETE, superceded by AoA. 

Concurrent Engineering - A sy stematic approach to the integrated, concurrent design of products and their related 
processes, including manufacture and support. Tliis approach is intended to cause developers, from the 
beginning, to consider all elements of the sy stem life cycle from requirements development through disposal, 
including cost, schedule and performance. 

Configuration item - An item that satisfies a documented set of requirements and is designated for separate 
configuration management to include any item required for logistic support or designated for separate 
procurement. 

Configuration management - For configuration items, (1) tlie identification and documentation of the configuration, 
(2) the control of changes to the items or their documentation, (3) configuration status accounting, and (4) the 
auditing to confirm that conformance to all requirements has been verified. 

Cost As an Independent Variable - Methodologies to acquire and operate affordable DOD sy stems by setting 

aggressive, achievable cost objectives and managing acliievemcnt of these objectives. Cost objectives shall 
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be set to balanee mission needs with projeeled out-year resourees. taking into aecount antieipalcd proeess 
improvements in both DOD and defense industries. 

COTS - Commereial off the Shelf 

CPM - Critieal Path Method 

CVX - Next generation aireraft earrier 

DAB - Defense Aequisition Board, the senior DOD aequisition review' board ehaired by the Under Seeretaiv' of 
Defense for Aequisition. The Viec Chairman of the Joint Chiefs of Staff is the Viee-Chair. Otlier members 
inelude tlie Deputy USD(Aequisition), Aequisition Exeeutives of the armed serv iees; the Direetor of Defense 
Researeh and Engineering; the Assistant Seeretaiy of Defense for Program Analysis and Evaluation; and the 
Comptroller of the DOD. 

DARC - Defense Aequisition Regulatory' Couneil, one of iwo eouneils authorized to generate ehanges to the Federal 
Aequisition Regulation (FAR). DARC members are from the Offiee of the Under Seeretaiy' of Defense for 
Aequisition. the DOD eomponents and NASA 
DCP - Deeision Coordinating Paper. OBSOLETE, supereeded by IPS. 

DD-21 - Next eombatanl slup program after DDG-51, also designated SC-21 
DDG-51 Fliglii IIA - Added helieopter support and lengthened base design 

Defense Aequisition Exeeulive Summary' (DAES) - summary' report of program progress presented to Offiee of 
Seeretary' of Defense (OSD) for review 
Design - noun : The result of designing. 

Design - verb: Arehiteeling and seleeling produets (ineluding proeesses) and eorresponding personnel manpower, 
skill levels, and speeialized traming that salisfv' all requirements and deseribing tliem so tliat the produets ean 
be manufaetured or eoded, verified, deployed, operated, supported, and disposed of and so that the personnel 
ean be seleeted and trained 
DMRS - Defense Mobilitv' Requirements Study 

DoD Direetive 5000.1 (Mareh 15, 1996) - States polieies and prineiples for all DoD aequisition programs and 

identifies the Department’s key aequisition offieials and forums, with supporting doeuments (DoD 5000.2-R) 
it provides mandatorv' proeedures for major defense aequisition programs and major automated information 
system. 

DT&E - Development Test and Evaluation, T&E eondueted to measure progress, usually of 

eoinponents/subsystems. and to assist the engineering design and development proeess and verify attainment 
of teelmieal performanee speeifieations and objeetives. Usually eondueted under eontrolled or laboralorv’ 
eonditions. Can be eondueted before or after produetion begins. 

DWL - Designed Water Line 

DYNAMO - System Dmamies modeling software 

Engineering Change Proposal (ECP) - a proposal to the responsible authoritv’ reeommending that a ehange to an 
original item of equipment be eonsidered, and the design or engineering ehange be ineorporated into the 
artiele to modiiS', add to. delete or supersede original parts. 
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Federal Acquisition Reform Act (FARA) - cited as the Federal Aequisition Reform Aet of 1995, requires 

go\’emmcnt construction projects to follow a two phase contracting approach; phase 1 will define technical 
requirements, approaches and evaluation procedures (but not detailed design specifications or cost ceilings) 
for open contract competition: phase 2 will award a contract based on the evaluation procedures delineated in 
phase 1. 

Federal Acquisition Streamlining Act (FASA) - cited as the "Federal Acquisition Streamlining Act of 1994", the act 
allows government agents to negotiate limited contracts (by amount, duration and scope) without the 
requirements of open competition and contract bidding. 

Functional Configuration Audit (FCA) - tlic formal examination of functional characteristics test data for 

configuration item, prior to acceptance, to verify' that the item has achieved the performance specified in its 
functional or allocated configuration identification. 

Functional analysis and allocation - The decomposition of each of the top-level functions to sub-functions to the 
point that each sub-function can be related to the elements of a physical hierarchy, the allocation of the top- 
le\'el performance requirements and design constraints to the functions and sub-functions, and the capture of 
the aggregation in a functional architecture. 

Functional architecture - The hierarchical arrangement of functions and their deeomposition to sub-functions and tlie 
allocation of the top level pcrfonnance requirements and design constraints to functions and sub-functions. 

Fmictional baseline - The initially approved documentation describing a s>'stcm's top level funetional and 

performance requirements and design constraints and all changes thereto. Tlie functional baseline can be 
changed only with Government approval. The functional baseline is usually initially approved near the end 
of the Program Definition and Risk Reduction Phase, as part of the procurement process for Engineering and 
Manufacturing Development. 

Hull, Mechanical & Electrical (HM&E) - The totality of non-payload (Upically combat systems) ship s>'stems and 
components. 

HVAC - Heating, Ventilation and Air Conditioning 

Integrated Logistics Support (ILS) - A disciplined unified, and iterative approach to the management and technical 
acti\aties necessar/ to (1) integrate support eonsiderations into s>'stem and component design: (2) develop 
support requirements that are consistently related to readiness objectives, to design, and to each other; 

(3) acquire the required support; and (4) provide the required support during the operational phase at 
minimum cost. 

Integrated Management Plan (IN4P) - A contractual description of the applicable documents, significant 

accomplisliments. accomplisliment criteria, events, and critical processes necessar>^ to satisfy all contract 
requirements. The completion of each significant accomplishment is determined by measurable 
accomplisliment criteria. The significant accomplishments have a logical relationship to each other and, in 
subsets, lead up to events. Each Event is, in tiun, complete when the significant accomplishments leading up 
to it are complete. The critical processes are described by narratives that include Objectives, Governing 
Documentation, and an Approach. The LN-IP includes an indexing scheme (sometimes called a single 
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numbering s>'stem) that links each significant aeeomplislimcnt to the associated CWBS element, event, 
significant aceomplishment criteria, and tasks presented in the Integrated Master Schedule (IMS). The data in 
the IMP defines the neccssar\^ aeeomplisliments for each event both for each IPT and for the contract as a 
whole. 

Integrated Master Schedule (IMS) - The schedule showing the time (calendar) relationship between significant 
aeeomplishmcnts, events, and the detailed tasks (or work packages) required to complete the contract. The 
FMS uses (and extends if nceessar\') the same indexing (or single numbering s>'steni) as used in the Integrated 
Master Plan (IMP). 

Integrated Product and Process Development (IPPD) - A management teelinique tliat simultaneously integrates all 
essential acquisition activities through the use of multi-disciplinary^ Integrated Product or Process Teams 
(IPTs). Specifically defined in the DOD Guide to Integrated Product and Process Development, 5 Feb 96. 

Integrated Product Team (IPT) - Team composed of specialists from all applicable functional disciplines working 
together (1) to deliver products and processes that affordably meet all requirements at acceptable risk and 
(2) to enable decision makers to make the right decisions at the right time by timely aeliic\ cment of the 
significant accomplislunents in the Integrated Master Plan (IMP). 

IPS - Integrated Program Summar\\ a DOD Component document prepared and submitted to the milestone decision 
authorit}^ in support of Milestone I, II. Ill and IV re\ iews. It provides an independent assessment of a 
program's status and readiness to proceed into the next phase of the acquisition eyele. 

Interface requirement - The fimctional and physical design constraints imposed on each other by two or more 
fimetions. items, or svstems or between a sv stem and a facility. Functional interfaces include signal, 
electrical, cleetroniagnetie, and software. Physical interfaces include keep-out volumes and mating surfaces 
and connections. 

Interface - The boundary’, physical or conceptual, between two or more functions. s> stems, or items or between a 
system and a facility at which interface requirements are set. 

IOC - Imtial Operational Capability’, the first attainment of the minimum capability’ to effectively employ a weapon, 
item or equipment, or sv stem of approv ed speeifie eharaeteristies, and which is manned or operated by an 
adequately trained, equipped, and supported military unit or force. 

JIT - Just In Time, a ‘‘pull" system, driv en by actual demand Goal is to produce or prov ide one part just-in-time for 
the next operation. Reduces stock inventones, but leaves no room for schedule error. As much a managerial 
pliilosophy as it is an inventory’ system. 

LBP - Length between Perpendiculars - usually the Icngtli of the ship at the waterline 

Legacy system - A s> stem/subsv stem/component associated with or envisioned for a DOD application, that exists or 
ean be anticipated to exist in a time frame that supports its melusion as part of a design being developed to 
met a current requirement. 

LFT&E - Live Fire Test & Evaluation, surv ivability testing and lethality’ testing required before full-seale 

production. Must be conducted (unless a waiver is approved by the USD(A)) on ACAT I and II programs 
for: 
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a. a covered s\stem (a vehicle, weapons platform, or conventional weapon s>'stem designed to provide some 
degree of protection to the user in combat, 

b. a major munitions or missile program or 

c. a product improvement program that will significantly affect the survivability of a covered s>^stem. 

Life Cycle Cost (LCC) - Life cycle costs include all Research and Development, Procurement, and Operation and 
Support costs from program inception to disposal of the last associated end item. The minimum categories of 
cost, wliich shall be used to estimate life cycle cost, are as follows: 

Research and Development Costs : Includes all costs associated with conceptual/feasibility studies, basic 

research, adv anced research and development, engineering design, fabrication and test of engineering 
protot>pe models (hardware), and associated documentation. These costs are generally non-recurring. 
Procurement Costs : Includes all costs associated with the acquisition of systems/equipment (once the 
Research and Development has been completed). Tlie following subcategories apply: 

Construction Cost : Includes all facility construction, capital equipment and facility maintenance. 
Manufacturing Cost : Includes all recurring and non-recurring costs associated with the production and 
test of multiple quantities of prime systems/equipment. 

Non-Recurring Manufacturing Cost : Includes all fixed, non-recurring costs associated with the 

production and test of operational sv stems/equipment. such as manufacturing management, 
manufacturing engineering, initial factory' tooling and test equipment, qualiU' assurance, first 
article qualification test (reliability' test, maintainability demonstration, support equipment 
compatibility, technical data verification, personnel test and evaluation, interchangeabiliU'. and 
environmental test) and related support, production sampling tests and related support. 

Recurring Manufacturing Cost : Includes all recurring end item production costs such as fabrication, 
subassembly and assembly, matenal and inventory' control, inspection and test, and packaging 
and sliipping. Sustaining engineering support required on a recurring basis is also included. 
Initial Logistics SuptX)rt Costs : Includes operational test and support eqmpment, training equipment 
and spare/repair parts material costs. 

Operation and Support Costs : Includes all costs associated with operating and maintaining the sv stem after 

delivery. Tlie following subcategories apply. 

Mission Personnel : Tlie costs of all pay and allowances for military' personnel required operating the 
end item 

Unit Level Consumption : The cost of fuel, repair parts and supplies, depot-lev'el repairables. training 
munitions and expendable stores, purchased services and the cost of temporarily assigned 
personnel. 

Inteniiediate Maintenance : The cost of maintenance and repair actions performed by tenders and 
shore-based inteniiediate maintenance activities. 

Depot Maintenance : Tlie cost of ship overhauls and the installation costs of perfonning sliip 
modifications (fleet modernization). 
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Sustaining Support : The cost of centrally pro\ided material (equipment associated with ship 

modifications), sustaining engineering support, software maintenance and any other require 
sustaining support. 

Indirect Support ; The cost of system specific training, permanent change of station and medical care. 
System Phase-Out and Disposal . The cost of condemning or disposing of an item. 

LOA - Length over All - Total length of the ship 
LSI - Lean Ship Initiative 
Margin - Reserve for future growth 
MARITECH - Marine Systems Technolog>' 

MILSPEC - Military' Specifications 

Molecules - System Eh namics Building Blocks generated by Jim Hines for Vensim and 15.875 
NAVSEA - Naval Sea Systems Command 
NAVSHPSSO - NAVSEA Shipbuilding Support Office 
Non-Developmental Item (NDI) - Any item that is 

(1) a\'ailable in the commercial marketplace or 

(2) previously developed and in use by a department or agency of the United States, a State or local 
Govermncnt, or a foreign Government with which the United States has a mutual defense cooperation 
agreement and tliat does not require umque upgrades or maintenance over its life-cycle to meet the 
current requirements. • 

In some cases NDI may be extended to include items that 

(a) have been developed but are not yet available in the commercial marketplace or in use by a Government 
entity or 

(b) require only minor modification or upgrade. 

Open s>'stem; A s}’stem architecture wluch uses a generally accepted set of industiy' standards to define s\ stem 
interfaces such tliat components or subsystems can be readily substituted or upgraded. 

Operating and support costs: see Life Cycle Cost 

OT&E - Operational Test and Evaluation, the field test, under realistic conditions, of any item (or key component) 
or w eapons, eqiupment, or munitions for the purpose of determining the effecti\'Cness and suitabilit}’ of the 
w eapons, equipment, or munitions for use in combat by typical mihtaiy' users; and the evaluation of the 
results of such tests. 

PC A - Physical Coirfiguration Audit, physical examination to \ erif\ that the configuration item(s) “as built' 
conforms to the technical documentation wliich defines the item. Approval by the govermnent program 
office of the Cl product specification and satisfactoiy' completion of tins audit establishes the product 
baseline. May be conducted on first full production or fist LRIP item. 

PDR - Preliminary Design Review; review' conducted to ascertain if the preliminaiv' design is to be committed to 
detailed design. Conducted for each configuration item to e\ aluate the progress, technical adequacy and risk 
resolution of the selected design approach, to detennine its compatibility w ith performance and engineering 
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requirements of the development speeifieation, and to establish the existenee and eompatibility of the 
physieal and fimetional interfaees among the item and other items of equipment, faeilities, eomputer 
programs and personnel. 

PERT - Probabilistie Evaluation and Review Teelinique 

Pliase - Period of time that eorresponds to one of the four primaiy^ phases of engineering and design. The phases 

inelude Coneept Design Phase, Preliminary Design Phase, Contraet Design Phase and Detailed Design Phase. 

Physical architecture - The physical hierarchy and the functional requirements and design constraints for each 

element in the hierarchy. It can be viewed as an intennediate step between the functional architecture and the 
physical hierarchy, on the one hand and the allocated baseline, on the other hand. 

Procurement cost - see Life Cycle Cost 

Product hierarchy, physical hierarchy - Tlie liierarchical arrangement of products, processes, personnel skill levels, 
and manpower levels that satisfy the functional baseline. The top entry in the hierarchy is the s> stem. The 
hierarchy extends to include all components and computer software units necessaiy^ to satisfy the functional 
baseline whether deliverable or not. It includes the prime operational hardware and software. Contractor- 
supplied support equipment, Government-in\’entor>^ support equipment, technical manuals, training programs 
for both Government and Contractor persoimel, Govermnent persoimel skill and manpower levels, spare parts 
requirements, and factor)' support equipment and tooling which collectively result in the s\ stem that satisfies 
the fimetional baseline. 

PRR - Production Readiness Review, a formal examination of a program to determine if the design is read)' for 
production, production engineering problems ha\ e been resolved and the producer has accomplished 
adequate planning for the production phase. 

PWBS - Product Work Breakdown Structure 

QA - Quality Assurance 

Requirements: Characteristics, attributes, or distinguisiiing features that a s)'stem or s)'stem element must have 
w ithin a stated environment or set of conditions in order to meet an operational need and comply w ith 
applicable policy and practices. 

Risk management - A documented process for the prospectn e (looking ahead) and recurring identification of what 
can go wrong, assigning a level of risk (e.g., Higli. Moderate, Low) to each risk, and planning and 
implementing mitigation steps for each commensurate with the le\'el of risk. 

Risk - A measure of the uncertainty' of attaining a goal, objective, or requirement and the consequences of not 
attaining it. Tlic uncertainty' is the result of one or more undesirable Ev ents that could occur during the 
system life cycle for which insufficient resources and time are programmed to overcome them. The 
consequences are inability to satisfy the operational militar)’ need and exceeding the programmed budget and 
directed schedule. 

RRF - Ready Reserv e Force 

SA'AR - Corvette sized combatant built by Ingalls for Israeli Navw. 

SC-21 - Next combatant ship program after DDG-51, also designated DD-21. 
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Scaleable - An attribute of design: develop designs, architectures, systems and transitions tecluiologies that era 
adaptable across a range of end items (such as ship classes). 

SCP - System Concept Paper, OBSOLETE, has been superceded by Integrated Program Summary (IPS) 

Selected Acquisition Report (SAR) - report of program progress presented to congress for budgetaiy^ oversight. 

SEMP - System Engineering Management Plan, includes plans for verification, risk alleviation, analyses and 
simulation of the system requirements. 

Ship Production Model - A virtual representation of a particular sliip being built at a shipyard 

Shipbuild - New project planning and progress tracking software wliich w ill use some elements of System Dynamics 

SFR - System Functional Review 

SHP - Shaft Horse Power 

Signature - Any attribute of any object by w hich a sensor can detect, locate and/or classify that object. 

Significant accomplishment criteria - Specific, measurable conditions that must be satisfactorily demonstrated 

before a significant accomplishment listed in an Integrated Master Plan (IMP) is complete and before work 
dependent on the accomplishment can proceed. 

Significant accomplislmient - A specified step or result tliat indicates a level of progress toward completing an event 
and, in turn, meeting the objectives and requirements of the contract. 

Simulation - The process of conducting experiments with a model (an abstraction or simplification) of an item 
and/or part or all of its operating enviromnent for tlie purpose of assessing its behavior under selected 
conditions or of evaluating various strategies for its operation within the limits imposed by developmental or 
operational criteria. Simulation may include the use of analog or digital devices, laboratorv’ models, or ’’test 
bed" sites. Simulations are usually programmed for solution on a computer; however, in the broadest sense, 
militarv' exercises and war games are also simulations. 

Specification tree - The hierarchical depiction of all the specifications needed to formally control the dev elopment, 
procurement, manufacture, integration, verification, and/or reprocurement during any part of the life cycle. 

SSR - Systems Requirement Review, conducted to ascertain progress in defining sv'stem technical requirements. 

Determines tlie direction and progress of the sv stenis engineering effort and the degree of convergence upon a 
balanced and complete configuration. Normally held during the CE/D phase, may be repeated after start of 
D/V to clarify' the contractor's understanding of redefincd/new' user requirements. 

STAR - Sy stem Threat Assessment Report. Documents the authoritative tlireat assessment tailored for and focused 
on a particular US defense acquisition program. Prepared by the Serv ice intelligence agency and validated by 
DIA at milestones 1, II, III & IV. Applicable to all tlireat driven defense acquisition programs. Must be 
system specific threat oriented. 

Stealth - Ability to evade radar 

Supportabilify - The degree to which planned logistics support (including sv stem design; test, measurement, and 
diagnostic equipment: spares and repair parts; teclmical data: support and facilities, transportation 
requirements: training, manpower: and software support) allow meeting svstem availabihfy and wartime 
usage requirements. 


145 


























SUPSHIP - Supervisor of Shipbuilding 

Surv ivabilit>' - The capability of a sv stem to avoid or withstand man-made hostile environments without suffering an 
abortive impairment of its ability' to accomplish its designated mission. 

Sustainability - To prolong performance over a period of time. 

System Dynamics - Methodologv' used to examine complex problems with non-linear relationships and feedback 

Sv'stem engineering - A process, applied iteratively throughout the System life cycle to translate stated objectives 
into design requirements, providing an integrated solution consisting of people, products and processes with 
the capability to satisty' the customer needs. 

Sv stem - The entity' to be designed as defined by the work breakdown structure. The entity for DD 21 Systems 
includes the ship and the infrastructure that supports ship operation, maintenance, readiness, etc. 

Technical Performance Measure (TPM) - A parameter that is related to progress toward meeting tlie program or 
contract functional requirements or goals and is assessed periodically and at certain events to estimate the 
degree to which the final \ alue will meet the anticipated or required level. 

TEMP - Test and Evaluation Master Plan, an overall test and evaluation plan, designed to identity' and integrate 

objectives, responsibihlies, resources, and schedules for all test and evaluation to be accomplished prior to the 
subsequent key decision points. Prepared, as early as possible in the acquisition process, it is updated as 
development progresses. 

Total Ownership Costs (TOC) - All the components of traditional Life Cycle Cost plus so-called linked, indirect 
costs (the fraction of supporting facilities/systems developed to support the given sv’stem.) 

Traceability' - The ability to relate an element of the functional baseline, functional architecture, physical hierarchy, 
allocated baseline, design baseline, and product baseline (or their representation in the decision data base) to 
any other element to which it has a master-subordinate (or parent-cliild) relationship. 

Trade studies An objectiv e comparison with respect to performance, cost, schedule, risk, and all other reasonable 
criteria of all realistic alternative requirements; architectures; baselines; or design, verification, 
manufactiuing, deplov ment, training, operations, support, or disposal approaches. 

Upgrade - A change from prev iously delivered items because of obsolescence of a part; a change in the militarv' 
need or tlireat; an operational, supportability, or training deficiency is identified; the s\ stem life must be 
e.xtended; a change in the law occurs; or an unsafe condition is detected. 

Vensim - System Dynamics modeling software 

WIP - Work In Progress 

Work Breakdown Structure (WBS) - A product-oriented hierarcliical tree composed of the hardware, software, 
services (including cross-product tasks such as systems engineering), data, and facilities that encompass all 
work to be carried out under the program or contract along with a dictionarv' of the entries in the tree. The 
WBS for the entire program is called the Program or Project WBS (PWBS). The WBS for the work under the 
contract is called tlie Contract WBS (CWBS) and is prepared in accordance witli the contract. 

Zones - Defines w hat functions are carried out in this portion of the ship e g. Machineiy\ Living, Storage 
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8.4 Design Task, Discipline and Duration Resources 

A vast quantiU' of material was anah^ed to pro\'ide both general and specific data supporting the naval ship 

design process model. To specifically callout these references at each instance of assessment (Chapters 4 and 5) 

would be inappropriate. Therefore, the following list and brief descriptions of reference materials will be given to 

provide the reader with knowledge of those resources: 

• And\^ Summers, Contract Design Historv^ for the Guided Missile Destroyer (DDG 31 Class) , Naval Sea Systems 
Command Washington DC, June 1987. Contains contract design schedules, hstings of resources (budgetary^ 
and personnel), listings of design products, descriptions of design processes and technical results. 

• And\’ Summers, DDG-51 Guided Missile Destroyer Preliminary Design History , Naval Sea Systems Command 
Washington DC, June 1984. Contains preliminary^ design schedules, listings of resources (budgetaiy^ and 
personnel), listings of design products, descriptions of design processes and technical results. 

• Bany^ Tibbitts, “Wliy Ships are Different’', John J. McMullen Assoc., 1991. General description of design 
spiral elements and practical aspects of nav al sy stem engineering. 

• Brown and Welsh, “FF13A Ship Design Math Model”, Massachusetts Institute of Technology^ course 
Applications of Naval Sy stem Design, Fall 1996. A MathCAD model using parametrics to develop a balanced 
surface combatant design, model demonstrates physical and empirical relationships relative to the design 
process. 

• C.R. Lloyd. Design Processes for the AEGIS Destroyer Program . Presentation by Bath Iron Works (BIW), 
November 18, 1997. Discussion of detailed design process, team structure and design products supporting the 
lead ship and manufacturing design of the DDG-51 class surface combatant. 

• Doug Hilton, “PME IDEF Model”, Naval Sea Sy stems Conmiand, September 13, 1994. IDEF description of 
concept and preliminary^ design applicable to naval design using the Product Model Extension (PME) program. 

• Edward Lewis, Pnnciples of Naval Architecture , Society of Naval Architects and Marine Engineers, Jersey 
City , NJ, 1988. Detailed descriptions of all aspects of naval ship design including hydrostatics, hydrodynamics, 
structural analysis and design integration. 

• Gale and Scott, “Early Stage Ship Design Seminar”, Society of Naval Architects and Marine Engineers, 

October 1995. Discussion of the elements of the design spiral for concept design and the basic relationships 
among those elements. 

• Greg Diggs, MAAST (Maritech Agile Shipbuilding Toolkit), Advanced Marine Enterprises Inc., March 26, 
1997, lutp://wx\w.ad \ mar .coni/fra inew ork/splash.htm. IDEF descriptions of complete design process for a 
generic “commercial” ship design. 

• John Dalton. Implementation of Mandatory Procedures for Major and Non-Major Defense Acquisition 
Programs and Major and Non-Major Information Technology Acquisition Programs (SECNAVINST 50()Q.2B) . 

Department of the Navy', Washington DC, December 6, 1996. Programmatic requirements relative to all phases 
of design process including listing of those design and risk assessment products required by' law, statute and 
direction. 
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• John Dalton. Program Decision Process (SECNAVINST 5420.188E) . Department of the Navy, Washington 
DC, October 31, 1995. Programmatic process description of lliose design products that must be presented at 
each milestone authorization. 

• Karaszevvski and Wade, Infrastructure Studv' in Shipbuilding: Report on Initial Findings Part 2, IDEFo 
Diagrams and Glossary, David Taylor Research Center. Bethesda, MA, Januarv' 3, 1991. IDEF descriptions of 
complete design process for a generic ‘’commercial” ship design. 

• Mahoney, Welsh and Moton ”13.412 DD13A Feasibility Design Requirements”, Massachusetts Institute of 
Technologv' course Appheations of Naval System Design, Fall 1997. Listing of design products required for 
concept and feasibility' assessment of a surface combatant design. 

• Myron Ricketts, Manual for Naval Surface Ship Design Technical Practices . Naval Sea Systems Command, 
Washington DC, 1980. Detailed descriptions of all design phases, all design products, and design inter¬ 
relationships necessaiy to enable individual NAVSEA engineers understand the impacts of design decisions on 
other design elements. 

• Naval Surface Warfare Center Carderock Division, “Getting Started & Tutorials: Adv anced Surface Ship 
Evaluation Tool (ASSET) Family of Ship Design Synthesis Programs", September 30, 1997. Description of the 
ASSET modules, formulations and svntliesis structure. 

• RADM Roger B. Home, “Concept to Commissioning. Improv ing the Ship Design. Acquisition and 
Construction Process: Strategic Plan”, Naval Sea Systems Command. Wasliington, DC, June 1991. Detailed 
analysis of nav al ship design process including statistical assessment of design timelines and costs, interviews 
and suggestions from design participants, and design organization stnictures. 

• Ron Ni.\, “T-AG9X Preliminarv7Contract Design Estimates”, Nav al Sea Systems Command, Januarv’ 16. 1987. 
Listing of design products, timelines and iterations (presented by design discipline and sub-discipline) estimated 
for an aaxiliary’ ship. 

• Scott Ripley, “Pre-Contract Product Development-Process Flow Chart”, Newport News Shipbuilding, 

December 11. 1996. IDEF diagram for all processes (engineering, cost, programmatic, legal, etc.) related to the 
development of an aircraft carrier. 

• Ship Design Group, Ship Design Project Histories: Volume I. II and HI . Naval Sea Systems Command. 
September 1978, May 1986 and August 1996. Complete descriptions of concept tliroiigh contract design for all 
naval ship designs developed from 19^0 through 1996. Includes manpower allocation, design disciplines, costs, 
sliip descriptions and timelines. 

• Storch, Hammon. Bunch and Moore, Ship Production , Society of Naval Architects and Mamie Engineers. 

Jersey City, NJ, 1995. Generic description of design products, design organization and production 
considerations relativ e to general ship design. 
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8.5 Baseline DDG-51 Task and Productivity Levels 

The following data has been extrapolated from the references in Chapter 8.4 and was used to calibrate the 


Naval Ship Design Process Model. 


Node 

Task Element 

Average ManMonths Per Task (Adjusted for DDG-61 Program) 

Concept 

Preliminary 

Contract 

Detailed 

Alt 

Plans 

Construct 

Program atic 

Program Management Tasks 

0 63 

118 

11.37 

9 65 

11 41 

6 85 

Requirements & Assessment 

0 21 

0 38 

5 86 

4 96 

5 84 

3 45 

Risk Mibgabon & Coordnaticn 

007 

038 

3 96 

3 22 

3 90 

2.30 

Systems Engineering 

Logsbes and Reliability 
Engineering 

1 02 

8 24 

11 72 

1681 

20 35 

11 63 

Desigr Integration & 
Specificstions 

6 61 

7 36 

15 94 

15.87 

17 93 

12 74 

Producibility and Production 
Engineering 

255 

21 28 

11 75 

17,63 

21.35 

1491 

Perform an ce-R equirement s 
Assessmoit 

3 36 

5 57 

6 20 

7 12 

8 62 

6 18 

Manning 

1 69 

2 01 

2 06 

3 93 

4 76 

2 89 

Hull Engineering 

Hull Geometry 

1 97 

5 57 

1 97 

3.16 

3 82 

3 30 

Wogit. Hull SubdMsicn & 
Hydrostatic Design 

1 96 

5 57 

0 19 

0 63 

0 76 

1 82 

Hydrodynamics-Resistance 

2 55 

5 57 

8 82 

11 35 

13.51 

8 36 

Hydrodynamics-Seakeeping 

255 

557 

8 82 

11.35 

13 51 

8 36 

H ydrodyn amic s-Maneuvenng, 
Appendage & Propeller Desigi 

2 55 

5 57 

1 26 

1 01 

1 22 

232 

Strvictures-Staic and Dynamic 
Design 

0 61 

5 57 

1 25 

1 19 

1 44 

201 

Space and Arrangements 

1,27 

0,15 

2 29 

2.02 

2.20 

1 59 

Machinery Systems 
Engineering 

Mach in ay Systems Design and 
Integr^icn 

357 

5 86 

1.75 

5 03 

5 93 

4.43 

Propulsion Systems 

0 77 

0 62 

1.38 

1.69 

2 05 

1 30 

Electneal Systems 

0 77 

0 62 

1 38 

1 69 

2 05 

1 30 

Auxiliary and Support Systems 

1,30 

0.84 

5.42 

5.06 

6,13 

3.75 

Deck, Handling and Aircraft 
Support Systems 

1.28 

1 47 

0 30 

1 57 

1.90 

1 30 

Mission Systems 
Engineehng 

Mission Systems Selection, 
Design and Integ^tion 

3 56 

1.94 

1 81 

3 70 

4 48 

3 10 

Topside Design and Integration 

13 02 

1 24 

2 60 

6.26 

7 58 

6.14 

Cost 

Cost Estimates & Analysis 

061 

1 02 

5 29 

4 23 

5.13 

3 26 

Totals and Averages 

2 37 

4 07 

4 93 

6 05 

7 21 

4 93 
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Analysis and Approval Periods (workdays) 



Average for 45 Programs from CNA Study 


CG-47 

t DCX5.51 

Node 

Task Element 

NAVSEA 

PMO 

Review/Approval Chain 

Review/Approval Chain 

o 

Prog-am Maiagement Tasks 

36 

42 5 

46.3 



1 

a 

Requiremerts & Assessment 

64 

53 0 

76 3 

1000 

24 0 

& 

Risk Million & Coordination 

75 

1150 

1400 



01 

Logistics and Rehability 
Engneenng 






■c 

c 

c 

c 

a 

c 

lU 

Design Integration & 

Specifi cations 






Productbility and Producbon 
Engneerng 

05 

15 0 

50.0 



£ 

c 

ts 

Vi 

Performance-Requirements 

Assessment 







Manning 







Hull Geometry 







Weight. Hull Suba^sion & 
Hydrostatic Design 






O) 

c 

•c 

Hyct-odjn amic s-R esi s tanc e 






• 

o 

c 

a 

H y ctod)namic s-Seakeepi ng 






c 

111 

3 

X 

H y cfod>Ti amic s-Maneuvenn g. 
Appendage & Propeller Design 







Structures-Static and Dynamic 
Design 







Space and Arrangements 






w 

£ 

Machinery Systems Design and 
Integation 






£ a> 

t i 

Propulsion Systems 






(0 C 

t c 

Electncal Systems 






If 

u 

Auxiliary and Support Systems 






% 

s 

Deck, Handling and Aircraft 
Support Systems 






v> 

1 ’ 

^: 

Mission Systems Selection, 
Design and Integation 






c S 
.9 ? 

s 

Topside Design and Integ-ation 






Cost 

Cost Estimates & Analysis 

94 

100 

35 0 



Totals and Averaaes 

52 

31 7 

57 5 

33 3 

80 
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8.6 Programmatic Task Development and Processing 
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MNS REVIEW, VALIDATION, AND APPROVAL PROCESS 
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Acquisition Program Baseline (APB) OPNAV Processing Procedures 



Figure 63 Acquisition Program Baseline (APB) Processing Procedures**^ 
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ORD REVIEW, VALIDATION. AND APPROVAL PROCESS 


ASreSSMENTS 

(N31) 


STEP * 


MILESTONE 
DEOSION 
4UTHC)RITY 
rNOTE S) 


JPD=jOINT POTENTI/M. 
DESIGNATOR 
^OINT 

-JOINT INTEREST 
iNDEPENPEN^ 


SPONSOR 

-PREPARE DRATTORD BASED ON 
A<5A ANALYSIS 
ACAHINSTER/TRaCK 
.ASSIGN SPONSOR priority 
-ENSURE PERFORMANCE 
PATA^CTERSf-IEET MISSION NEED 


JiNITIATE .AOA ANAL'tSISl 


SERVICES JPD RE MEW C91, SI, 
33 AND OTHE RS AS TOPICS 

relate 


USA. LKAf. USMC 
(SERVICE ORDT 


SERVICE OFD 


STEP 3 


(NOTE 2) 


SPONSOR 

-CONSOLIDATE COMMENTS 
-PREPARE SMOOTH ORD 
SION « FORWARD 

-FOR POTENTIAL ACAT ID COORDINATE 
VMTH NmOFCR JROC BRIEF 
R38TNOTE 31 


iNtTi>:LREMEvVA#C COMMENT 

NOSI 

N 095 


Na 3 - (ONCs REM^Af) 


N81 REMEMCANO COMMENT 
-ADMINISTER AND TRACK 
-PRIORITIZE NEED 

-FORWARD ORD TO JROC AND OTHER SERVICES 
FORlNTERCPERAaJTYEVALUATION AND 
JONT ASSESSMENT 
-STAFF SERVCE ORDsFOR OPNAVJPD 
ASSESSMEN-^'NOTE 21 


JOINT STAFF FOR 

NTEROPERABILITYCERTIFICATION 


NOTE 

C) COPT PBOVt ED FOR INFORWtATlON 
CO fOROftfk IWITH JOHT, HTI3?ESTMNS 
OR NO PROCSFOING MNS-SS^Wie 
REASSESS JOINT POTENT PA/VPUCAI ION 
© M8 CHAR RESOURCES REOUIRBWENTS 
ReAEW90AftD(fOF) f*ETSASREO«fi£D 
(0 SB* AHD C*l SYSTW RCLAia) PR0GR<«S 
© uawc PROGRPfflSWITKUSN BSON. 
SPONSORSHIP 

Ax:Ar It. Ill IV- Mj eioo rse tehn acwc fob 
appro VPl 

ACAT I MS BJDOBSe. THEN PONC FOR 
PPPSOMSi 

®1 "llSSTO HE OECBlON AUTHORITY wop) 

•USD (WIT TOR ACAT IQ 
. ASH(Br»«iFORA£ATIC. I 
S’TSCO'VPeC/nRFM for ACAT II. IV 
(7) CNO'AXiaAIESAMDRPFROVEaFOB MAVT. 
PHD FOR JROC WMEN OfclEOATEO 


STEP S 

SPONSOR 

-CCCLECT ENDORSEMENTS H 
F0RV-'A8D TON81 
FORWiT^D DRAFT APB TO N01 


(PROMDE AOV/V^CE COPVTONaiO) 



FINAL FLAO LEVEL ETOORSEMENT 

N031 

N096 


STEPS 


STEP 10 


-ENDORSE ACAT I ORD 
FWO RECOMMENDATIONS TO CNO 
■REMEW JROCBR’EF 


CNO 

VCNO VAUDATE i 
APPRO';C 
ACAT 1C, D 

Icffg INOTS T]' 


SPONSOR 

FORWARD APPROVED ACAT 1C,II 
lll,IVO«DWDA(NOFE6; 

AFTER SERI.<>01 TED 


JROC 

VALIDATE KEY 
PERfOPWANCE 
PARAMETERS 
EXTRACTED 
n?CM ACAT ID CRD 


-H jso-A^ rj j 


Figure 64 Operational Requirements Document (ORD) Review, Validation and Approval Process^^^ 
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8.7 Naval Ship Design Process Model 


The following fomiulalions arc show n in the format of Vensim code. For electronic copies of the formulatioru 
contact the author at tomkimlav@sprintmail.com. 


Contracted Assign Rate [Phase,Discipline]= 

Current Phase [Phase] *MIN(Conlractor New' Assignments[Phasc,Discipline]/Conlractor Assign Period\ 
[Phase], Contractors Available [Phase,Discipline 
]/Conlractor Assign Period[Phase]) 

~ Manpovver/Month 


Adjust Rate[Phasc]= 

0.4,0.3,0.3,1.1,0.7 
~ Dimensionless 


Adjusted Desired Manpower[Phase,Discipline]= 

Desired Manpower[Phase,Discipline]*Effect of Schedule Gap on Desired Manpower [Phase,\ 
Discipline] 

Manpower 


Effect of Schedule Gap on 0\'ertimc[Phase.Discipline]= 

Effect of Schedule Gap on Ov ertime f(Schedulc Gap[Phase,Discipline]) 
~ Dimensionless 


Net Contractors= 

SUM(Contractors Phase[Phasc!]) 
~ Manpower 


Effective E\pcrienced[Phase,Discipline]= 

Contractor Experienced[Phase,Disciplinc]*CKertime[Phase,Discipline] 
Manpower 

Experienced Contractor times assigned overtime 


Maximum Overtime= 

1.75 

~ Dimensionless 

~ Maximum monthly overtime that may be assigned of personnel 


Phase Task Change[Phase,E>iscipline]= 

Rescope Rate[Phase,Discipline] 

~ Tasks/Month 

I 

Effect of Approval Phase on Desired Manpower[Phase]= 

Effect of Approv al Phase on Desired Manpower f(Approval Phase[Phase]) 
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Dimensionless 


Phase Tasks[Phase.Discipline]= INTEG ( 

Phase Task Change[Phase,Discipline]. 

Initial Tasks|Phase,Discipline]) 
~ Tasks 


NAVSEA Assign Rate[Phase,Disciphne]= 

Current Phase[Phase]*NnN(NAVSEA New Assignments[Phase,Disciplinej/NAVSEA Assign Period\ 
,NAVSEA Available[Phase.Discipline]/NAVSEA Assign Period 

) 

~ Manpower/Month 


Rescope Rate[Phase,Discipline]= 

Current Phase[Phase]*Rescope Fractioii[Phase]*MAX(0,Input)*Initial Tasks[Phase.Discipline\ 
]/Approval Period[Phase] 

~ Tasks/Month 

~ The rate of design rescope by the DoN/DoD is indicator tliat the pliase \ 
impacted by rescope is the current phase (equals 1) times a random \ 
generation of desired change introduction (input) times the a fraction of \ 
the baseline (initial) tasks im olved in the rescope o\ er the time \ 
required to introduce rescope (a period concurrent with the approval \ 
period) 


Net ProdiictiviU' Rate[Phase,Discipline]= 

Adjust Rate[Pliase]*Avg Design Rate[Phase,Discipline]*EffectOfFatigueOnProducti\ity[Phase\ 
,Disciphne]*EffectOfScheduleGapOnProductivity' 

[Phase,Discipline] ^Effect of Personnel Level on Productivit> [Phase.Discipline] 
Tasks/(Manpower*Montli) 


Contractor New Released[Phase,Discipline]= 

IF THEN ELSE(Current Phase[Phase]=0.Contractor New [Phase.Discipline]/Contractor Release Penod\ 
,MIN(Contractor New Desired Release[Phase,Discipline]/Contractor Release PeriodContractor 

New'\ 

[Phase,Discipline]/Contractor Release Period)) 

Manpower/^Ionth 


Effect of NAVSEA Percent[Phase.Discipline]= 

Effect of NAVSEA Percent f(NAVSEA Percentage[Phase]/NAVSEA Participation Desired Percentage\ 
[Phase.Discipline]) 

~ Dimensionless 


NAVSEA New' Release Rate[Phase,Discipline]= 

IF THEN ELSE(Current Phase[Phase]=0,NAVSEA New [Phase.Discipline]/NAVSEA Release Period\ 
,MIN(NAVSEA New' Desired Releascphase,Discipline]/NAVSEA Release Period,NAVSEA 

New[\ 

Phase,Discipline]/NAVSEA Release Period)) 

Manpower/Monlh 
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Release of new project personnel is the minimum of the desired release and \ 
the release constraint (manning over time required to release personnel) 


Desired Duration[Phase]= 
18,8,10,16,6 
-- Montli 


Avg Design Rate[Concept,Discipline]= 

1.58, 4.8, 15.36, 0.98, 0.15, 0.39, 0.3, 0.59, 0.51, 0.51, 0.39, 0.39, 0.39, 1.64, 0.79\ 
,0.28, 1.3, 1.3,0.77, 0.78, 0.28 
, 0.08, 1.64 H 

Avg Design Rate[Prehmmar>,Discipline]= 

0.85, 2.63, 2.63, 0.12, 0.14, 0.05, 0.18, 0.5, 0.18, 0.18, 0.18, 0.18, 0.18, 0.18, 6.83\ 
,0.17, 1.62, 1.62. 1.19, 0.68, 

0.52, 0.8, 0.98 H 

Avg Design Rate[Contract,Discipline]= 

0.09, 0.17, 0.25, 0.09, 0.06, 0.09, 0.16, 0.49, 0.51, 5.15, 0.11, 0.11. 0.8, 0.8, 0.44\ 
,0.57, 0.72,0.72, 0.18, 3.35,0.55 

,0.38, 0.19 H 

Avg Design Rate[Lead Ship,Discipline]= 

0.1, 0.2, 0.31, 0.06, 0.06, 0.06, 0.14, 0.25, 0.32, 1.6, 0.09, 0.09, 0.99, 0.84, 0.5\ 

, 0.2, 0.59, 0.59, 0.2, 0.64, 0.27, 


0.16, 0.24 H 

Avg Design Rate[Manufacturmg,Discipline]= 

0.09, 0.17, 0.26, 0.05, 0.06, 0.05, 0.12, 0.21, 0.26, 1.32. 0.07, 0.07. 0.82, 0.69, \ 
0.45,0.17, 0..49, 0.49, 0.16, 0.53, 

0.22,0.13, 0.2 

-- Tasks/(Month*Manpo\ver) 


Baseline Desired Manning[Phase,Discipline]= 

Imtial Tasks[Phase,Disciphne]/(Avg Design Ratc[Phase,Discipline]*DesiredDuration[\ 
Phase]) 

~ Manpower 

- Baseline Maiming Requirement is the Number of Tasks over the tasks per man \ 
required to meet the desired schedule 


Effect of Schedule Gap on Overtime f( 

[(0,0)-(10,2)],(0.1),(l,l),(2,l),(10,2)) 

Dimensionless 

-- For schedule gap of 1 or less\!\!\! 


Initial Schedule Projection[Concept]= 

Desired Duration[Concept] ~| 

Initial Schedule Projection[PreIiminar\']= 

Desired Duration[Concept]+Desired Duration[Preliminar>] —| 

Initial Schedule Projection[Contract]= 

Desired Duration[Concept]+Desired Duration[Preliminaiv']+Desired Duration[Contract] 

Initial Schedule Projection[Lead Ship]= 

Desired Duration[Concept]+Desired Duration[Preliminar>']+Desired Duration[Contract]+Desired Duration\ 
[Lead Ship] 
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Initial Schedule Projection[Manufacluring]= 

Desired Duration[Concept]+Desired Duration[Preliniinar\]+Desired Duration[Contract]+Desired Duration\ 
[Lead Sliip]+Desired Duration [Manufacturing] 

~ Month 


Net Desired Manpower^ 

SUM(Desired Manpower Phase [Phase!]) 
~ Manpower 


NAVSEA Participation Adjusted Percentage[Phase,Discipline]= 

NAVSEA Participation Desired Percentage[Phase,Discipline]*Effect of NAVSEA Percent[Phase\ 
.Discipline] 

Dimensionless 

~ The desired manning level of NAVSEA relative to Contractors 


NAVSEA Participation Desired Percentage[Phase.Discipline]= 

MIN(NAVSEA Participation Nominal Percentage[Phase],NAVSEA Participation Nominal Percentage\ 
[Phase] *Effect of Approval Phase on NAVSEA Percent 
[Phase]*Effect of Available Budget on NAVSEA Percent[Phase]) 

-- Dimensionless 


Total Contractors Assigned[Phase]= 

(SUM(Effective Experienced[Phase,Discipline!])+SUM(Effective New[Phase.Discipline!])\ 
)*Current Contract Fee[Phase] 

~ Manpower 

The total contractors assigned as a cost is tlie sum of current contractors \ 
times tlie additional percentage charged to current contracts (10% overhead \ 
fee) 


NAVSEA Percentage[Phase]= 

NAVSEA Phase[Phasel/MAX( 1,NAVSEA Phase [Phase]+Contractors Phase[Phase]) 
~ Dimensionless 


NAVSEA Experienced Release Rate[Phase,Discipline]= 

IF THEN ELSE(Current Phase[Phase]=0,NAVSEA Experienced[Phase,Discipline]/NAVSEA Release 

Period\ 

,MIN(NAVSEA Exp Desired Release[Phase.Discipline]/NAVSEA Release Period,NAVSEA 

Experienced\ 

[Phase.Discipline 
]/NAVSEA Release Period)) 

~ ManpowerMonth 

~ Release of experienced persoimel is the minimum of the desired release and \ 
tlie release constraint (manning over time required to release personnel) 


Desired Manpower[Phase,Discipline]= 

MAX( DesiredAccomplislungRate[Pliase,Discipline] / (Avg Design Rate[Phase.Discipline]\ 
*Adjust Rate[Phase]),Baseline Desired Manning[Phase,Discipline]) 

Manpower 
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Net NAVSEA= 

SUM(NAVSEA Phase[Phase!]) 
- Manpower 


Contractor Experience Release Rate[Phase.Disciplme]= 

IF TIffiN ELSE(Current Phase [Phase] =0. Contractor Experienced[Phase,Disciplme]/Contractor Release 

Period\ 

,MIN(Contractor Exp Desired Release[Phase,Discipline]/Contractor Release PeriodContractor 

Experienced\ 

[Phase,Discipline] 

/Contractor Release Period)) 

~ Manpower/Month 


Schedule Shift [Concept,Discipline]= 

(Indicated Completion Datc[Concept,Discipline]-Desired Schedule[Concept.Disciplme])\ 

/Time to Shift Schedule —| 

Schedule Shift[Preliminar\\Discipline]= 

MAX(Indicated Completion Date[ConccptDiscipline]-Desired Schedule[Concept,Disciphne\ 

],Indicated Completion Date[Preliminar\.Discipline]-Desired Schedule[Prelirninar\\Discipline\ 
])/Timc to Shift Schedule —| 

Schedule Shift[Contract,Discipline]= 

MAX(Indicated Completion Date[Concept,Disciplme]-Desired Schedule[Concept,Discipline\ 

],MAX(Indicated Completion Date[Prcliminar\\Discipline]-Desired Schedule [T^eliminar>\ 
.Disciphne],Indicated Completion Date 

[Contract.Discipline]-Desired Schedule[Contract,Discipline]))/Time to Shift Schedule\ 

Schedule Shift[Lead Ship,Disciplinc]= 

MAX(Indicated Completion Date[ConceptDisciphne]-Desired Scliedulc[Concept.Discipline\ 

],MAX(Indicated Completion Date[Preliminar>,Discipline]-Desired Schedule[Preliminar\\ 
,Disciplme],MAX(Indicated Completion Date 

[Coiitract.Discipline]-Desired Schedule[Contract,Discipline] Jndicated Completion Date\ 

[Lead Ship.Disciphne]-Desired SchedulefLead Ship,Discipline])))/Time to Sliift Schedule\ 

Schedule Shift[Maiiufacturing,Discipline]= 

MAX(Indicated Completion Date[Concept,Discipline]-Desired Schedule[Concept,Discipline\ 

],MAX(Indicated Completion Date[Preliminar> ,Discipliiie]-Desired Schedule[Preliminar\\ 
,Discipline],MAX(Indicated Completion Date 

[Contract,Discipline]-Desired Schedule[Contract,Discipline],MAX(Indicated Completion Date\ 

[Lead Ship,Discipline]-Desired Schedule[Leacl Ship,Discipline],Indicated Completion Date\ 
[Manufacturing,Discipline 

]-Dcsircd Schedule[Manufacturing,Discipline]))))/Timc to Sliift Schedule 

~ Month/Moiith 

~ The shift of design schedule is the indicated completion date o\’er tlie \ 
time required to initiate the full time shift...note that each phase date \ 
is shift by preceding phase schedule sliifts as well 


Percent Hiase Complete[Phase]= 

Total Approved Tasks[Phase]/SUM(Phase Tasks[Phase,Discipline!]) 

~ Dimensionless 

Tlie Percent Completion of the current phase is the ratio of the total \ 
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approved tasks to the total phases tasks initially required to be done 


Current Contract Fee[Phase]= 

Percentage of RFP Contracts[Phase]*K(l-Percentage of RFP Contracts[Phase])*l , 1 
-- Dimensionless 

Tlie current contract fee represents the effective cost of contractors as a \ 
function of those contracted at RFP rate (100% cost) and those on current \ 
NAVSEA contracts (additional 10% overhead to cost) 


Ov’ertime[Phase,Disciplme]= 

MIN(Maxinumi Overtime,Effect of Schedule Gap on OvertimcfPhase,Discipline]*Ov’ertime A 
(Indicated Overtime Required[Phase,Discipline])) 

~ fraction 

~ Tlie current assigned overtime is the maximum of maximum ov ertime to assign \ 
and the overtime profile (assignment schedule) for a given indicated \ 
ov ertime requirement 


Effect of NAVSEA Percent f( 

[(0,0)-(l,l)].(0,l),(0.5,l),(0.75,0.75),(1,0)) 
-- Dimensionless 


Effective Nevv[Phase.Discipline]= 

Contractor Nevv[Phasc.Discipline]*Ovcrtime[Phase,Discipline] 
- Manpower 

New Contractors times the overtime assigned 


Prob Discoverv' by Phase[Phase]= 

0.4.0.37,0.3,0.23,0.2 
-- Dimensionless 

-- The probability of discov ery of an error increases for each phase as more \ 
individuals are involved with tlic project and increasing detail is examined 


Prob Defect Discoveiy [Phase,Disciplinc]= 

Effect of Errors on Discoverv [Phasc.Disciplinc]*Prob Discover}' by Phase[Phase] 

~ Tasks/Tasks 

- Probability of Discovery by Design Phase times the changing probability' of \ 
discoverv (Effect of Errors on Discoverv) as the total errors for the \ 
current phase increases 


Comp Rate f[Phase.Discipline]= 

MlN(WIP[Phasc,Discipline]^in Comp Pcriod[Phase.Discipline].Effective Personnel Lev eA 
[Phase,Discipline]*Net Productivity^ Rate 
[Phase.Discipline]) 

~ Tasks/Month 

- Tlie average completion rate for the WIP remaining in each discipline \ 

during each phase is the lesser of time limited completion (WIP/minimum \ 
period to complete) and resource limited completion (personnel av ailable \ 
times net rate of productiv ity per person) 
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Review Rate[Phase,Discipline]= 

Re\iew Phase[Phase]*Compleled[Phase,Discipline]/Review Period[Phase] 

~ Tasks/Month 

-- The rate of NAVSEA Review of Tasks is the completed tasks over the time \ 
required to review a task...note that this assumes task review is \ 
continuous (more likely this is not the case...and leads to the \ 
possibility of draining completed tasks prior to proper iteration through \ 
the feedback matrix... 


Review Ratio Actual [Phase]= 

(SUM(Completed[Phase,Discipline!])+SUIVl(Approved[Phase,Discipline!])+SUM(Revie\v[Phase\ 
,Discipline!]))/SUM(Initial Tasks[Phase,Discipline!]) 

~ Dimensionless 

- The Ratio of total tasks available for or already approved to the total \ 
intial tasks is the total of tasks released at review and those residing \ 
as Approved divided by the initial tasks. ..by phase. 


Review^ Ratio Dcsired[Phase]= 
0 . 8 , 0 . 9 , 0 . 95 , 0 . 5 , 0.5 
~ Tasks/Tasks 


Review Error Rate f[Phase,Discipline]= 

Adj Prob Defect[Phase,Discipline]*Prob Defect Discovery [Phase,Discipline]*(Rcview[Phasc\ 
,Disciphne]/Time to Detect Errors [Phase]) 

~ Tasks/Month 


Review Phase[Pliase]= 

Review Phase Effect f(Revie\v Ratio Actual[Phase]/Review Ratio Dcsired[Phase]) 
Dimensionless 

~ Tlie approval phase is active (1) for actual to desired ratios greater than \ 

1 and inactive (0) for ratios less than 1 


Review Phase Effect f( 

[( 0 , 0 )-( 2 , 1 )],( 0 , 0 ),( 0 . 537764 , 0 . 0921053 ),( 0 . 773414 . 0 . 25 ),( 0 . 954683 , 0 . 820175 ),( 1,1 ),(\ 

2 , 1 )) 

Dimensionless 

~ The approval Phase Effect Function compares the ratio of Approval Ratio \ 
Actual to Desired for net ratios greater than 1, the approv al pliase is \ 
active (1) for ratio less than I the approval phase is not active (0)\!\! 


Review Phase Nct= 

SUM(Review Phase[Pliase!]) 
~ Dimensionless 


Internal Error Rate f|Phase,Discipline]= 

Adj Prob Defect[Phase,Discipline]*Prob Defect Discovery [Phasc.Discipline]*(Completed\ 
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[Pliasc,Discipline]/Timc to Detect Errors [Phase]) 
Tasks/Month 


EffectOfScheduleGapOnProductivity[Phase,Discipline]= 

EffectOfScheduJeGapOnProductivitv' f(Schedule Gap[Phase,Discipline\ 

]) 

-- dninl 


Adj Prob Defect[Phase,Discipline]= 

Prob Defect by Phasc[Phase]*Effect of Errors on Defects[Phase.Discipline] 
~ Tasks/Tasks 


NAVSEA Experienccd[Phasc,Disciplme]= INTEG ( 

NAVSEA Experience Gain Rate[Phase,Disciplinc]-NAVSEA Experienced Release Rate[PhaseA 
Discipline], 

0 ) 

~ Manpower 

~ The accumulation of NAVSEA personnel with direct experience with the \ 
current design Project is 0 plus the rate of experience gain less the \ 
release rate of experienced personnel from the project 


NAVSEA Available[Phase,Discipline]= INTEG ( 

NAVSEA New Release Rate[Phase,Disciplinc]+NAVSEA Experienced Release Rate[Pliase.Discipline\ 
]-NAVSEA Assign Rate[Phasc.Discipline], 

NAVSEA Baseline Persomicl[Phase,Discipline]) 

~ Manpower 


Effect of Errors on Dcfects[Phase.Discipline]= 

Effect of Errors on Defects f(Errors Disco\ ered[Phase,Discipline]/lnitial Tasks[Phase\ 
.Disciplme]) 

~ Dimensionless 


Effect of Errors on Defects f( 

[(0,())-(T1)],(0,1X(0.001,().9)A0.01,0.8)A0.T0.5).(0.247734,0.()745614)A1,0)) 
~ Dimensionless 


Effect of Errors on Discover\'[Phase,Disciplme]= 

Effect of Errors on Discovery^ f(Errors Disco\ ered[Phase.Disciplme]/Initial Tasks[Phase\ 
,Discipline]) 

~ Dimensionless 


NAVSEA Experience Gain Ratc[Phase,Disciphne]= 

NAVSEA New[Phase,Disciphne]/NAVSEA Experience Gain Period[Phase] 

-- Manpower/Montli 

The rate of transfer of persoimel from new' to project to experienced witli \ 
tlie project is tlie number of personnel o\ er the average time to acquire \ 
experience 
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Error Discoverv Rate[Phase,Discipline]= 

Internal Error Rate[Phase,Disciplme]+Review Error Rate[Phase.E>iscipline] 
-- Tasks/Month 


NAVSEA New[Phase,Discipline]= INTEG ( 

NAVSEA Assign Rate[Phase,Discipline]-NAVSEA Experience Gain Rate[Phase,Discipline]-NAVSEA 
New Release Rate\ 

[Phase^Discipline] 

0) 

~ Manpower 


Prob Defect bv Phase[Phase]= 

0.2.0'19,0.15.0.11,0.1 
~ Dimensionless 

-- Probability of a defect will change with each phase due to increasing \ 
individuals and detail 


Total Errors per Phase[Phase]= 

SUM(Errors Discovered[Phase,Discipline! ]) 
~ Tasks 


Effect of Errors on Discover\' f( 

[(0,0)-(l,l)],(0,lX(6.001,0.9),(0.0L0.8),(0.1,0.5),(0.5,0.1X(k0)) 
~ Dimensionless 


Errors Discovered[Phase,Discipline]= INTEG ( 
Error Discoveiw' RatefPhase.Discipline], 
0 ) 

~ Tasks 


Indicated Overtime Required[Phase.Disciphne]= 

IF THEN ELSE(Personnel Assigned[Phase,Discipline]<=0. Adjusted Desired Manpower[Phase\ 
,Discipline]/Man, Adjusted Desired Manpower 
[Phase,Discipline]/Personnel Assigned[Phase,Discipline]) 

~ Dimensionless 


Man= 

1 

~ Manpower 

~ The unit for a single person 


Effect of Personnel Level on Productivitv [Phase,Disciplme]= 

Effect of Persomiel Level on Productivity f(Personnel Assigned[Phase.Discipline]/Man\ 

) 
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Dimensionless 

Described in literature as "communication overhead", increased levels of \ 
personnel assigned to a project can acKersely effect productiviw from the \ 
standpoint of required personnel interaction, and down time for meetings, \ 
etc... 


Design Spiral Rate[Phase,Discipline]= 

Feedback FractionfPhase]*MIN(Completed[Phase,Discipline]/TIME STEP,MAX(Comp Rate|Phase\ 
,Al]*Design Spiral Matrix 
[ A1,Discipline 

],MAX(Comp Rate[Phase,A2]*Design Spiral Matrix[A2,Discipline],MAX(Comp Rate[Phase,A3\ 
]*Design Spiral Matrix [A3,Discipline],MAX( Comp Rate 
[Phase,Bi]*Design Spiral Matrix[Bl,Discipline],MAX(Comp Rate[Phase,B2]*Design Spiral Matrix\ 
[B2,Discipline].MAX(Comp Rate[Phase,B3 

] 

*Design Spiral Matrix[B3,Discipline],NLAX(Comp Rate [Phase, B4]*Design Spiral Matrix[B4\ 
,Discipline],MAX(Comp Rate[Phase,B5]*Design Spiral Vlatrix 
[B5,Discipline],MAX(Comp RatePhase.Cl]*Design Spiral Matrix[Cl,Discipline],MAX(Comp Rate\ 
[Phase,C2]*Design Spiral Matrix[C2,Discipline 

],MAX(Comp Rate[Phase,C3|*Design Spiral Matnx[C3,Discipline],MAX(Comp Rate[Pliase,C4\ 
]*Design Spiral Matrix[C4,Discipline],MAX(Comp Rate 
[Phase,C5]*Design Spiral Matrix[C5,Discipline],MAX(Comp Rate[Phase,C6]*Design Spiral Matrix\ 
[C6,Discipline],MAX(Comp Rate [Phase, C7 

] 

*Design Spiral Matrix[C7,Discipline],MAX(Comp Rate[Phase,Dl]*Design Spiral Matrix[Dl\ 
,Discipline],MAX(Comp Rate[Phase,D2]*Design Spiral Matrix 
[D2.Discipline],MAX(Comp Rate[Phase,D3]*Design Spiral Matrix[D3,DisciphneJ,MAX(Comp Rate\ 
[Phase,D4]*Design Spiral Matrix[D4,Discipline 

],MAX(CompRate[Phase,D5]*Design Spiral Matrix[D5,Disciplme],MAX(Comp Rate[Phase,El\ 
]*Design Spiral Matrix[El,Discipline].MAX(Comp Rate 
[Phase,E2]*Design Spiral Matrix[E2,Discipline],Comp Rate[Phase,Fl]*Design Spiral Matrix\ 
[FLDiscipline]))))))))))))))))))))))) 

-- Tasks/lVIontli 

-- Design feedback (due to concurrent design assumptions inherent to the \ 

Naval Design Process) is the fraction of impacted design tasks (Feedback \ 
fraction) times tlie minimum of completed tasks rate constraint (completed \ 
over design phase time measure.. .one month) and the maximum "work \ 
interference" rate for the given discipline compared to the other 22 \ 
disciplines (Feedback matrix times the disciplines completion rate) 

I 

Effect of Personnel Level on Productivih’ f( 

[(0.0)-(l00,l)],(0,l).(25.6798.(k964912),(52.8701,0.894737),(80.0604,0.714912),(100,\ 

0.5)) 

-- Dimensionless 


Funding Period^ 
12 


Month 


Rescope Fraction[Phase]= 
0.05 


167 


bf; 












Dimensionless 


Current Phase[Phase]= 

Current to Future Phase[Phase]*Current to Past Phase [Phase] *Effect of Percent Complete on Project End\ 
[Phase] 

Dimensionless 

~ To determine if a design phase is a Current Pliase (equals 1), multiply the \ 

Current to Future Phase indicator times the Current to Past Phase \ 
indicator...if equals 0, the phase is not yet started (Current to Future \ 

Phase is 0) or already over (Current to Phase is 0) 


Percent Complete at Project End[Phase]= 
0.8,0.9,0.9,0.95,0.95 
~ Dimensionless 


Effect of Percent Complete on Project End f( 
[(0,0HK1)],(0,1),(0.999,1X(1.0)) 

~ Dimensionless 


Effect of Percent Complete on Project End[Phase]= 

Effect of Percent Complete on Project End f(Percent Phase Complete[Phase]/Percent Complete at Project 

End\ 

[Phase]) 

~ Dimensionless 


Internal Error Rate[Phase,Discipline]= 

Internal Error Rate f[Phase,Discipline] 

~ Tasks/lVIonth 

~ The rate of internal Q/A and defective discovery is the probabiliK of a \ 
defect times the probability of discovering the defect times the minimum \ 
of tasks available for inspection (completed over the time to detect) and \ 
the inspector constraint (QA constraint) 


Max Indicated Completion Date[Phase]= 

Indicated Completion Date[Phase,Al] 
~ Month 


NAVSEA Participation Nominal Percentage [Phase]= 

0.3,0.2,0.2,0.1,0.1 
~ Dimensionless 

- The desired manning level of NAVSEA relative to Contractors 


Personnel Assigned[Phase,Discipline]= 

NAVSEA Ne\v[Phase,Discipline]+Contractor Ne\v[Phase,Discipline]+Contractor Experienced\ 
[Phase,Discipline]+NAVSEA Experienced 
[Phase,Discipline] 

~ Manpower 
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Total personnel (NAVSEA and Contracted, novice and experienced with the \ 
project) assigned to each discipline during a given time of each design \ 
phase 


Effect of Available Budget on NAVSEA Percent[Phase]= 

Effect of Available Budget on NAVSEA Percent f(Available to Desired Budget [Phase]) 
~ Dimensionless 


Approval Phase Net= 

SUM( Approval Phase [Phase!]) 
~ Dimensionless 


Planned Annual Funding[Phase]= 

3.2e+006,1.5e+007,1.62e+007,6.44e-K)07,2.14e+007 
-- Dollars 

~ Initial Values determined from DDG-51 program (NAVSEA Ship Design \ 
Histories and Acquisition Budget results) 


GettingFatigued[Phase,Discipline]= 

(Overtime[Phase.Discipline] - Fatigue[Phase,Discipline]) / TimeToGetFatigued 
~ fraction / Month 


Net Review[Phasel= 

SUVI(Review[Phase,Discipline!]) 
~ Tasks 


Effect of Approval Phase on Desired Manpower f( 
[(0,0)-(l,l)],(0,l),(1.0.5)) 

~ Dimensionless 


Effect of Approval Phase on NAVSEA Percent [Phase ]= 

Effect of Appro\al Phase on NAVSEA Percent f(Approval Phase[Phase]) 
~ Dimensionless 


Effect of Appro\ al Phase on NAVSEA Percent f( 
[(0,0)-(1.2)],(0.1),(1.1.25)) 

-- Dimensionless 


Available to Desired Biidget[Phase]= 

IF THEN ELSE(Perceived Funding Requirements[Phase]<=0,4,A^■ailable Budget[Phasej/Perceived 
Funding Requirements\ 

[Phase]) 

~ Dimensionless 


Effect of Available Budget on Contractors f( 
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[(0,0)-(8.10)],(0,0),(0.5,0.2).(0.75,0.5X(l,lX(2,4),(3.86707/).71053).(6,8),(8,8)) 
-- Manpower 

-- For available budget fractions near 0 (available is low) the fraction of \ 
contractors to be hired is directly proportional...as available to need is \ 
very large, more contractors will be hired up to a ver\^ large portion \ 
(overfunding) at which contractors are released\!\!\! 


Effective Personnel Level[Phase,Discipline]= 

(Contractor Experienced[Phase,Discipline]*PDY Contractor Experienced Factor+Contractor New 
[Phase,Discipline]*PDY Contractor New Factor+NAVSEA ExperiencedfPhase,Discipline]*PDY 
NAVSEA Experience Factor\ 

+NAVSEA New 

[Phase,Discipline]*PDY NAVSEA New Factor)*Ov'ertime[Phase,Discipline] 

Manpower 

~ The effective personnel level is the sum of the effective number of \ 
personnel assigned (number of personnel times an experience factor) 


CK ertime f( 

[(0,0)-(2,2.6)],(0.1),(0.175258,1),(0.417526,1).(0.747423,1),(L 1),(1.25.1),(L5, L2\ 
),(1.7,1.4),(1.8,1.6),(1.9,1.8),(2,2)) 

-- fraction 


Funding Gap[Pliase]= 

Perceived Funding Requirements[Phase]-Available Budget[Phase] 
~ Dollars 


Fiscal Reset= 

IF THEN ELSE(Fiscal Counter= 12.Fiscal Counter/TIME STEP,0) 
^ Dimensionless 


Net Approved[Phase]= 

SUM(Approved[Phase,Discipline!]) 
-- Tasks 


Change to Budget[Phase]= 

Current Phase[Pliase]*Fimding Gap[Phase]/Time to Change Budget 
~ Dollars/Month 


Net Complcted[Phase]= 

SUM(Completed[Phase.Discipline!]) 
-- Tasks 


Contractors Phase[Phase]= 

SlJM(Contractor Experienced[Phase,Discipline!])+SUM(Contractor New[Phasc,Discipline!]\ 

) 

-- Manpower 
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Desired Manpower Phase [Phase]= 

SUM(Adjusted Desired Manpower[Phase.Discipline!]) 
~ Manpower 


NAVSEA Phase[Phase]= 

SUM(NAVSEA Experienced[Phase,Discipline!])+SU]VI(NAVSEA New[Phase,Disciphne!]) 
~ Manpower 


Contractor New Desired Release[Phase.Discipline]= 

IF THEN ELSE(-Manpower Shortage[Phase,Discipline]>0,MAX(0, ABS(Manpower Shortage[Phase\ 
,Discipline])*(l-NAVSEA Participation Adjusted Percentage[Phase,Discipline])*(ABS(l\ 
-Effect of Available Budget on Contractors[Phase]))),0) 

~ Manpower 

-- When personnel supluses exist, new contractors are released based as the \ 
fraction of manpower shortage desired as contractors 


Review Error Rate[Phase,Discipline]= 

Review Error Rate f[Phase.Discipline] 

~ Tasks/Month 

~ The rate of external Q/A and defective discoverv' is the probability of a \ 
defect times the probability of discovering the defect times the minimum \ 
of tasks available for inspection (reviewed tasks over the time to detect) \ 
and the inspector constraint (QA constraint) 


Fiscal Counter Increase= 
1 


Dimensionless 


TimeToGetFatigued= 1 
~ Month 


Total Tasks[Phase]= 

Net Appro\ed[Phase]+Net Completed[Phase]+Net Review [Phase]+Net TB Coord[Phase]+Net TBD\ 
[Pliase]+Net WlP[Phase] 

~ Tasks 


Net TB Coord[Phase]= 

SUM(TBCoord[Phase,Discipline!]) 
~ Tasks 


Net TBD[Phase]= 

SUM(TBD[Phase,Discipline!]) 
~ Tasks 


Net WIP[Phase]= 
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SUM(WIP[Phase,Discipline!]) 

Tasks 


Fatigue[Phase,Discipline]= INTEG ( 

GettingFatigued[Phase,Discipline]. 

1 ) 

-- fraction 


Contractor New Assignments[Phasc,Discipline]= 

MAX(0,Effect of Available Budget on ContractorslPhase]*Manpower Shortage[Phase,Discipline\ 
]*(1-NAVSEA Participation Adjusted Percentage[Phase,Discipline])) 

Manpower 

Assignments will occur as the Manpower Shortage times the fraction of \ 
non-NAVSEA personnel required times a factor for budget available 


Effect of Available Budget on Conlractors[Phase]= 

Effect of Available Budget on Contractors f(Available to Desired Budget[Phase]) 
-- Manpower 


Fiscal Counter^ INTEG ( 

Fiscal Counter Increase-Fiscal Reset. 
0 ) 

~ Month 


Perceived Funding Requirements [Phase]= 

Total Contractors Assigned[Phase]*Contactor Cost*Current Phase[Phase]*ABS(Max Indicated 
Completion Date 

[Phase]-Time) 

~ Dollars 


Program Budget Rate[Phase]= 

Annual Fimding[Phase]*Current Phase[Phase]/Funding Period 
~ Dollars/Month 


Effect of Schedule Gap on Desired Manpower f( 

[(-40,0)-(40,10)],(-24,0.25).(-12.().5),(0,I),(3J.25).(12,2),(24.4)) 
~ Dimensionless 


Manpower Shortage[Pliase.Discipline]= 

Adjusted Desired Manpower[Phase,Discipline]-Personnel Assigned[Phase,Discipline] 
~ Manpower 


Contract Establishment Rate[Phase.Discipline]= 

Percentage of RFP Contracts[Phase]*Conlractor Pool[Phase.Discipline]/Contracting with RFP Rate\ 

[Phase,Discipline]+(l-Percentage of RFP Conlracts[Phase])*Contractor Pool [Phase, Disciplme\ 
]/Contracting with Existmg NAVSEA Contracts[Phase,Discipline] 
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Manpower/Month 


nimimumCompletionDuration= 

1 


Month 


NAVSEA New Assigiinicnts[Phase,Discipline]= 

IF THEN ELSE(lVIanpo\ver Shortage[Phase,Discipline]>0,Manpower Shortage [Phase,Discipline\ 
]*NAVSEA Participation Adjusted Percentage[Phase,Disciplme],0) 

~ Manpower 

~ For existing manpower shortage, the assigment of NAVSEA Personnel is the \ 
desired fraction of NAVSEA personnel times the required personnel 


Schedule Gap[Phase,Discipline]= 

Indicated Completion Date[Phase,E)iscipline]-Desired Schedule[Phase,Discipline] 
~ Month 


NAVSEA Exp Desired Release[Phase,Discipline]= 

IF THEN ELSE(NAVSEA New Desired Release[Phase.Discipline]<0,0,MAX(0,NAVSEA New Desired 

Release\ 

[Phase,Discipline]-NAVSEA New[Phase,Discipline])) 

Manpower 

-- When NAVSEA personnel are being released (NAVSEA New Desired Release is \ 
positive) experienced pcrsoimel are released only after all new personnel \ 
have been released 


DesiredAccomplishingRate[Phase,Discipline]= 

Perceived TBD[Phase,Discipline] / Remaining Design Phase Duration[Phase,Discipline] 
Tasks/Montli 


Remaining Design Phase Duration[Phase,Discipline]= 

MAX(minimumCompletionDuration, Desired Schedule[PIiase.Discipline] - Time) 
~ Month 


NAVSEA New Desired Release[Phase.Discipline]= 

EF THEN ELSE(Manpower Shortage[Phase,Discipline]>0,0,NAVSEA Participation Adjusted Percentage\ 
[Phase.Disciplme]*ABS(Manpower Shortagc[Phasc.Discipline])) 

-- Manpower 


Percentage of RFP Contracts[Phase]= 

O.OLO.l,0.2,0.8,09 
-- Dimensionless 

-- The a\ erage fraction of total contracts which are RFPs \ ice existing \ 
NAVSEA contracts 


Effect of Schedule Gap on Desired Manpower[Phase,DiscipIine]= 
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Effect of Schedule Gap on Desired Manpower f(Schedule GapfPhase.Discipline]) 
- Dimensionless 


Contractor Exp Desired Release[Phase,Discipline]= 

IF THEN ELSE(Contractor New Desired Release[Phase,Discipline]<0,O.MAX(0,Contractor New Desired 

Release\ 

[Phase,Discipline]-Contractor New[Phase,Discipline])) 

~ Manpower 


Contractor Release Peri ^d= 

1 

Montli 

Time required to release persomiel from the current project is 

I 

Contractors Available[Phase,Discipline]= INTEG ( 

Contractor Experience Release Ratc[Phase.Discipline]+Contractor New Released[Phase,Disciphne\ 
]-Contracted Assign Rate[Phase.Discipline]+Contract Establishment Rate[Phase,Discipline\ 

J. 

0 ) 

Manpower 


NAVSEA Experience Gain Period[Phase]= 

6 

^ Month 

~ Months required for individuals to acquire full working knowledge of the \ 
current project 


NAVSEA Release Period= 

1 

~ Montli 

~ Time required to release persomiel from the current project is 


Contractor New[Phase,Discipline]= INTEG ( 

Contracted Assign Rate[Phase.Discipline]-Contractor Experience Gain Rate[Phase.Discipline\ 
]-Contractor New' Released[Phase,Discipline], 

0 ) 

-- Manpower 


EffectOfFatigueOnProductivity[Phase,Discipline]= 

EffectOfFatigueC)nProducti\it>' f(Fatigue[Phase,Discipline]) 
~ dnml 


Contracting witli Existing NAVSEA Contracts[Phasc,Disciplinel= 

3 

Montli 

Months required to negotiate design work tluough existing NAVSEA Contracts 
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Contracting with RFP Rate[Phasc,Discipline]= 

18 

~ Month 

Months required to negotiate design work through new (RFP-request for \ 
proposals) contracts 


PDY Contractor Experienced Factor= 

1.1 

Dimensionless 

-- Contractor Experienced Personnel have an increased productiviK of 20% \ 
greater than that of an av erage designer 


Contractor Baseline Personnel[Phase,Discipline]= 

50 

-- Manpower 

~ NAVSEA Personnel available for assignment to the project by discipline and \ 
phase 


Contractor Experience Gain Period[Phase]= 

6 

Month 

~ Months required for individuals to acquire full working knowledge of the \ 
current project 


Contractor Experience Gain Rate[Phase,Discipline]= 

Contractor Nevv[Phase,Discipline]/Contractor Experience Gain Period[Phase] 

~ Manpovver/Montli 

~ The rate of transfer of persomiel from new to project to experienced with \ 
tlie project is the number of personnel over the average time to acquire \ 
experience 


Contractor Experienced[Phase,Discipline] = INTEG ( 

Contractor Experience Gain Rate [Phase. Discipline]-Contractor Experience Release Rate\ 
[Phase.Disciphne], 

0 ) 

~ Manpower 

~ The accumulation of NAVSEA personnel with direct experience with the \ 
current design Project is 0 plus the rate of experience gain less the \ 
release rate of experienced personnel from the project 


Indicated Completion Date[Phase.Discipline]= 

Current Phase[Phase]*(Time+IF THEN ELSE(Estimated Comp Rate[Phase,Discipline]<=0,60,\ 
Perceiv ed TBD[Phase.Disciphne]/Estimatcd Comp Rate 
[Phase.Disciplinc])) 

~ Month 

- The estimated montlis to completion (per disepline per phase) is 0 if the \ 
phase is inactive (cither passed or not yet started) or is the TBD divided \ 
by the current rate of completion (personnel by personnel \ 
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productivity)...note at phase start, no personnel are assigned so an \ 
artificial estimate of 60 months is set. 


Contractor Pool[Phase,Discipline]= INTEG ( 

-Contract Establishment Rate(Phase,Discipline], 

Contractor Baseline Personnel(Phase,Discipline]) 

~ Manpower 

-- The pool of available contractors not available because contracts are not \ 
yet in place to allow their use 


PDY NAVSEA Experience Factor= 

1.1 

-- Dimensionless 

-- NAVSEA Experienced Personnel have an increased productivity of 20% greater \ 
tlian that of an ax erage designer 


EffectOfFatigueOnProducth itv f( 

[(0.0)-(4.4)],(0,l),(l.il.01),(1.5,1.5).(2,2).(3 
-- drmil 


EffectOfScheduIeGapOnProductivity f( 

[(-10,0)-(10,1.75)],(-10,0.75),(0,0.9),(0.757732,0.904605),(1,1),(1.5,1.1),(2.50755A 
1.25877).(3.83686,1.52741),(5,1.684),( 10,1.75)) 

~ dmnl 


PDY NAVSEA New Factor= 

0.85 

-- Dimensionless 

~ NAVSEA Personnel new to the project have an increased productivity of 20% \ 
less than tliat of an a\ erage designer 


Estimated Comp RatelPhase,Discipline]= 

Avg Design Rate[Phase,Discipline]*Personnel Assigned[Phase,Disciplinel 
~ Tasks/Month 


PDY Contractor New Factor^ 

0.85 

~ Dimensionless 

~ Contractor Personnel new to the project have a producti\ity of 20% less \ 
than that of an average designer 


Spending Rate[Phase]= 

Total Contractors Assigned[Phase]*Contactor Cost 
~ Dollars/Month 


Desired Tasks to Assign[Phase,Discipline]= 
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Personnel Assigned[Phase,Discipline]*Nct Productivity Rate[Phasc,Discipline]*Design Phase Duration\ 
[Phase] 

~ Tasks 

~ The desired number of tasks to be assigned (by discipline) at a gh en time \ 
in a phase is the number of personnel available to work times the \ 
effective productivity of those personnel times montlis number of months \ 
into the project 


Design Phase Duration[Phase]= INTEG ( 

Design Phase Time Step[Phase], 

0 ) 

~ Month 

^ From the start of a design phase, how many months have passed... 


Design Phase Time Measure= 

1 

~ Month 

~ The basic measurement of design duration is 1 month of time 


Design Phase Time Step[Phasc]= 

Current Phase[Phase]*Dcsign Phase Time Measure/Design Phase Time Measure 
~ Month/Month 

~ The rate of increase of the design duration for a current phase (Current \ 

Pliase equals .1) is the current model time step over the basic measurement \ 
of time (1 month) 


Assign Rate[Phase.Disciplinc]= 

MIN(TBD[Phase,Discipline]/Assign Period.Desircd Tasks to Assign[Phase,Discipline]/Assign Period\ 

) 

~ Tasks/Month 

~ Tlie assigmnent rate is tlic minimum of the assignable task constraint (TBD \ 
o\ er assignment period) and the desired task assignment constraint \ 

(desired tasks for assignment over the assigmnent period) 


Release Rate[Phase,Discipline]= 

Baseline Tasking[Phase,Discipline]*CuiTent Phase[Phase]/TIME STEP 
~ Tasks/Month 

~ At the commencement of a design phase, all baseline tasks arc released to \ 
TBD for assignmenet to designers, the release is dependent on the phase \ 
becoming active...time step is used to pro\ ide the release in a single \ 
pulse. 


Time to Detect Errors[Phase]= 

1 

~ Month 

-- Tlie minimmn time (by phase) required to detect an error in a task 


Current to Future Phase[Concept]= 
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Current to Future Phase[Prclimmar\ ]= 

Effect of Percent Phase Complete on Current to Future f(Percent Phase Complete[Concept\ 
]/Percent Phase Complete Desired[Concept]) —| 

Current to Future Pliase[Contract]= 

Effect of Percent Phase Complete on Current to Future f(Percent Phase Complete[Preliminarv'\ 
]/Percent Phase Complete Dcsired[Prelmiinar>']) ~| 

Current to Future Phase [Lead Ship]= 

Effect of Percent Phase Complete on Current to Futnre f(Percent Phase Complete[Contract\ 
]/Percent Phase Complete Desired[Contract]) —| 

Current to Future Pliase[Manufactiu'ing]= 

Effect of Percent Pliase Complete on Current to FuUire ffPercent Phase Complete[Lead Ship\ 
j/Percent Phase Complete Desired[Lead Slupj) 

~ Dimensionless 

A design pliase can start (equals 1) when the previous design phase ratio \ 
of complcted/approved tasks to desired approved tasks is greater than 1 \ 

(by the Effect of Percent Phase Complete function.) 


WIP[Phase,Discipline]= INTEG ( 

Assign Rate[Phase,Discipline]+Coord Rate[Phasc.Discipline]-Comp Rate[Phase,Discipline\ 

]. 

0 ) 

Tasks 

Work is progress is the number of tasks released from initial work (assign \ 
rate) plus the rework tasks returmng from coordination (coord rate) less \ 
the tasks completed by designers (comp rate) 


Net Comp Rate= 

SUM(Comp Rate[Concept.Discipline!])+SUM(Comp Rate[Preliminaiy\Disciplme!])+SlJM(Comp Rate\ 
[Contract,Discipline! ] )+SUM(Comp Rate 
[Lead Ship.Disciplinc!])+SUM(Comp Rate[Manufacturing,Discipline!]) 

-- Tasks/Month 


Approi al Phase[Phase]= 

Appro\ al Phase Effect f(Approval Ratio Actual[Phasel/Appro\ al Ratio Dcsired[Phase]) 
~ Dimensionless 

~ Tlie approval phase is acti\ e (1) for actual to desired ratios greater than \ 

1 and inactive (0) for ratios less than 1 


Approval Pliase Effect f( 

[(0.0)-(2,l)l,(0,0),(0.75,0),(0.999,0),(Ll),(2.1)) 

-- Dimensionless 

-- The approval Phase Effect Function compares the ratio of Appro\ al Ratio \ 
Actual to Desired for net ratios greater than 1. the approval phase is \ 
active (1) for ratio less than I the approval phase is not active (0) 


Approval Ratio Actual [Phase]= 

(SUM(Approved[Pliase,Discipliiie!])+SUM(Rcvie\v[Phase,Disciphnc!]))/SUM(Initial Tasks[\ 
Phase.Discipline!]) 

-- Dimensionless 
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Tlie Ratio of total tasks a\ ailable for or alreach' approved to the total \ 
intial tasks is tlie total of tasks released at rev iew and those residing \ 
as Approved divided by the initial tasks ..by phase. 


Completed[Phase,Discipline]= INTEG ( 

+Comp Rate[Phase.Discipline]-Review RatefPhase^Discipline]-Internal Error Rate[Phase\ 
.Discipline]-Design Spiral Rate[Phase. 

Discipline], 

0 ) 

~ Tasks 

~ Completed tasks are increased by the completion rate (Comp Rate) and \ 

decreased by release of tasks for NAVSEA review (Review Rate), rework of \ 
tasks due to concurrent feedback (Design Feedback Rate) and rework due to \ 
discovered errors (Defective Rate) 


Approve Rate[Phase.Discipline]= 

Approval Phase[Phase]*(ReviewlPhase.Discipline]/Approval PeriodfPhase]) 

^ Tasks/Month 

The rate of approval of tasks by DoN/DoD is the indicator that tasks \ 
lev els will support approv al process (Approval Phase equals 1) times the \ 
approv al rate (rev ievvable tasks over the time required to review a task) 


Effect of Percent Phase Complete on Current to Future f( 
[(0,())-(2 J)].(0,0),(0.999,0).( 1,1),(2,1)) 

~ Dimensionless 


Effect of Percent Phase Complete on Current to Past f( 
[(0,0)-(2,l)],((kl),(0.999,l).(l,0),(2,0)) 

~ Dimensionless 


Comp RatelPhase.Discipline|= 

Comp Rate f[Phase,Discipline] 

Tasks/Month 

~ Tlie rate of completion of tasks is the average completion rate for tasks \ 
(...see resource sector for first order control of comp rate) 


TBD[Phase.Discipline]= INTEG ( 

-Assign RatelPhase.Disciplme]+Release Rate[Phase,Discipline]+Rescope Rate[Phase,Discipline\ 

]. 

0 ) 

~ Tasks 

~ TBD is the quantitv of tasks available for assigmnent increased by release \ 

(at phase start) and by rescoping of the project (design change \ 
introduction) by authorities, TBD is decreased by the assignment rate \ 

(assigning tasks to designers) 


Current to Past Phase[Concept]= 

Effect of Percent Phase Complete on Current to Past f(Ciirrent to Future Phase[Preliminarv \ 
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])H 

Current to Past Phase[Preliminan']= 

Effect of Percent Phase Complete on Current to Past f(Current to Future Phase[Contract\ 

])H 

Current to Past Phase[Contract]= 

Effect of Percent Phase Complete on Current to Past f(Current to Future Phase[Lead Ship\ 

])“l 

Current to Past Phase[Lead Ship]= 

IH 

Current to Past Phase[Manufacturing]= 

1 

-- Dimensionless 

~ A phase is finished (equals 0) when tlie next design phase has achieved an \ 
inicator value (Current to Future Phase) for phase initiation (equals \ 
l)...acliieved through the table function Effect of Percent complete. 


TBCoord[Phase,Discipline]= INTEG ( 

+Design Spiral Rate[Phase.Discipline]-Coord Rate[Phase.Discipline]+Intemal Error Rate\ 
[Phase,Discipline]+Review^ Error Ratc[Phasc,Discipline], 

0 ) 

~ Tasks 

- The tasks requiring coordination prior to rework are increased by the \ 
tasks requiring rework (design feedback rate, defective rate and reject \ 
rate) less those tasks completing coordination and returning to the work \ 
cycle (coord rate) 


NAVSEA Baseline Personnel[Phase.Discipline]= 

7 

~ Manpower 

~ NAVSEA Personnel available for assignment to the project b>' discipline and \ 
phase 


Desired Schedule[Phase.Discipline]= INTEG ( 

Schedule Shift[Phase,Disciplme], 

Initial Schedule Projection [Phase]) 

~ Month 

~ The Desired Schedule is the initial schedule (months to phase completion \ 
from project start) estimate for each phase increased (or decreased) by \ 
the rate of schedule shift 


Perceived TBD[Phasc,Discipline]= 

Current Phase[Phase]*MAX(0,Imtial Tasks[Phasc.Discipline]*Percent Phase Complete Desired\ 
[Phase]-Perceived Completcd[Phase.E>iscipline]) 

Tasks 

The perceived TBD (for an active phase as detennined by the boolean \ 

Current Phase) is the maximum of 0 (floor value) and the tasks required to \ 
close the phase (initial tasks times transition ratio) minus the perceiv ed \ 
completed tasks. 


Net Personnel Assigned^ 
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SUM(Nel Personnel Assigned Phase [Phase!]) 

~ Manpower 

-- Net Personnel Assigned (by project) is tlie sum of personnel assigned by \ 
phase 


Annual Funding[Phase]= INTEG ( 

Change to Budget [Phase], 

Planned Annual Funding[Phase]) 
- Dollars 


Net Perceived TBD[Phase]= 

SUM(Perceived TBD[Phase.Discipline! ]) 

-- Tasks 

-- Net Perceived TBD (by phase) is the sum of TBD by design discipline 


Effect of Available Budget on NAVSEA Percent f( 

[(0,0)-(l,l)]X0,l),(0.05,l),(0.1,0.9),(0.2,0.75),(1,0.75)) 
-- Dimensionless 


Available Budget[Phase]= INTEG ( 

-Spending Rate[Phase]+Program Budget Rate[Phase], 

1 ) 

~ Dollars 


Coord Rate f[Phase.Discipline]= 

TBCoord[Phase,Discipline]/Average Coord Period[Phase,Discipline] 

~ Tasks/Month 

~ Average Coordination Rate is the Tasks available for coordination over the \ 
time required to coordinate a task 


Coord Rate[Phase.Discipline]= 

Coord Rate f[Phase,Discipline] 

~ Tasks/Month 

The rate of coordination of tasks is the average coordination rate for \ 
tasks (...see resource sector for first order control of coord rate) 


Net Coord Rate [Phase]= 

SUM((roord Rate flPhase.Discipline!]) 
~ Tasks/Month 


Time to Change Budget= 
36 


Month 


Contactor Cost= 
6597 
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Dollars/(Month*Manpovver) 

The average monthly cost per contractor, including overhead costs, in FY96 \ 
dollars 


Spent Budget[Phase]= INTEG ( 
Spending Rate[Phase]. 
0 ) 

- Dollars 


NAVSEA Assign Period= 
1 

~ Montli 


Time to Shift Schedule= 
24 

-- Month 


Perceived Completed[Phase,Discipline]= 

Revie\v[Phase,Discipline]+CompIeted[Phase,Discipline]+Approved[Phase.Discipline] 
-- Tasks 

-- Perceived completed is the number of tasks in review plus those awaiting \ 
re\iew (completed) plus those approved 


Contractor Assign Period[Phase]= 
1 


Montli 


Net Perceived Completed[Phase]= 

SUM(Perceived Completed[Phase,Discipline!]) 

~ Tasks 

~ Net perceie\ ed completed tasks (by phase) are the sum of all perceived \ 
completed tasks by design discipline 


Net Personnel Assigned Phase[Phase]= 

SUM(Personnel Assigned[Phase,Disciphne! ]) 

Manpower 

Net Current Personnel Assigned (by phase) is the sum of persoimel assigned \ 
by design discipline 


Step Down Time= 
0 


Month 


Pink Noise = INTEG(Change in Pink Noise,0) 

-- Dimensionless 

-- Pink Noise is first-order autocorrelated noise. Pink noise provides a realistic \ 
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noise input to 

models in which the next random shock depends in part on the previous \ 
shocks. The user 

can specify the correlation time. The mean is 0 and the standard deviation \ 
is specified 

by the user. 


Inputs 

MAX(Pink Noise,MIN(STEP{Step Height.Step Up Time)+ 

(Pulse (Juantity/TIME STEP)*PULSE(Pulse Time,TIME STEP)+ 

RAMP(Ramp Slope,Ram,p Start Time,Ramp End Time)+ 

Sine Amplitude*SIN(2*3.14159*Time/Sine Period)+ 

STEP(l,Noise Start Time)*Pink Noise, 1-STEP(Step HeightStep Down Time))) 
-- Dimensionless 

~ Input is a dimensionless variable vviiich provides a variefy^ of test input patterns, \ 
including a step, 

pulse, sine wave, and random noise. 


Change in Pink Noise = (White Noise - Pink Noise)/Noise Correlation Time 
~ 1/Month 

-- Change in the pink noise value: Pink noise is a first order exponential smoothing \ 
delay of the white 
noise input. 


Sine Amplitude= 

1 

-- Dimensionless 

~ Amphtude of sine wave in customer orders (fraction of mean). 

I 

Sine Period= 

25 

~ Month 

~ Period of sine wave in customer demand. Set initially to 50 weeks (1 \ 
vear). 

I 

Step Height^ 

1 

-- Dimensionless 

~ Height of step input to customer orders, as fraction of initial value. 


Pulse (Juantitv^ 

1 

~ Month 

-- The quantity to be injected to customer orders, as a fraction of tlie base value of \ 
Input. 

For example, to pulse in a quantify’ equal to 50% of tlic current value of \ 
input, set to 
.50. 
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Pulse Timc= 

62 

-- Month 

-- Time at vvliich the pulse in Input occurs. 


White Noise = Noise Standard Deviation*((24*Noise Correlation Time/TINIE STEP)'^0.5*(RANDOM 0 1\ 
0-0.5 

)) 

-- Dimensionless 

~ White noise input to the pink noise process. 


Noise Correlation Time = 4 
~ Month 

~ The correlation time constant for Pink Noise. 


Ramp Slope=0 

~ 1/Month 

Slope of the ramp input, as a fraction of the base value (per week). 


Ramp Start Time= 

0 

-- Month 

Start time for the ramp input. 


Ramp End Time=le+009 
~ Month 

~ End time for tlie ramp input. 

I 

Noise Standard Deviation= 

0.5 

~ Dimensionless 

Tlie standard deviation of the pink noise process. 

I 

Noise Start Time= 

0 

-- Month 

-- Start time for the random input. 


Step Up Time= 
0 


Month 

Time for the step input. 


Approved[Phase,DisciplineI= INTEG ( 
Approve Rate[Phase,Discipline], 
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0 ) 

Tasks 

The total tasks (by discipline) approv ed by DoN/DoD and considered remov ed \ 
from the phase 


Total Approv ed Tasks[Phase]= 

SUM( Approved[Phase.Discipline! ]) 

Tasks 

The total approved tasks for all disciplines in a single design phase 


Approval Period[Phase]= 

1,1,1,0.125,0.125 
~ Month 

The current time required to rev iew a task by DoN/DoD is considered 3 \ 
montlis 


Approv al Ratio Desired[Phase]= 
0.8, 0.9, 0.95,0.5,0.5 
Tasks/Tasks 


Revievv[Phase,Disciplinel= INTEG ( 

Review Rate[Phase.Discipline]-Approv e Rate[Phase,Discipline]-Revievv Error Rate[Phase\ 
,Discipline], 

0 ) 

~ Tasks 

~ Tlie tasks reviewed by NAVSEA are increased by the rev iew rate and \ 

decreased by those tasks rejected to rework (errors discovered) and tliose \ 
design tasks provided to DoN/DoD for final approv al 


Baseline Tasking[Phase,Discipline]= INTEG ( 

-Release Rate[Phase,Disciplme]. 

Initial Tasks[Phase,Discipline]) 

Tasks 

~ Tlie Initial Stock of design tasks for the 23 design disciplines and 5 \ 

phases, the stock is drained to 0 at tlie commencement of each phase (tlie \ 
phase becomes active.) This stock initiates tlie model for a phase 


Percent Phase Complete Desired[Phase]= 
0.8, 0.9, 0.95, 0.75, 0.5 
~ Tasks/Tasks 


Pliase: 

Concept, Preliminarv, Contract, Lead Ship, Manufacturing 
~ Tasks/Tasks 


Assign Period= 
1 
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Month 

The average lime required to assign a task is 1 month 


Discipline: 

Ak A2, A3, Bl. B2, B3. B4, B5, Cl, C2. C3, C4, C5, C6, C7. Dl. D2, D3, D4, D5, El, \ 
E2,F1 


Feedback: 

Al, A2, A3, Bl, B2, B3, B4, B5, Cl, C2, C3, C4, C5, C6, C7, Dl, D2, D3, D4, D5, El, \ 
E2,F1 


Initial Tasks[Concept,Discipline]= 

8, 8, 12, 2, 1, 1, 4, 2, 4, 6, 2, 1, 2. 7, 5. 3, 2, 2, 2, 1, 3, 2, 3 —| 

Initial Tasks[Preliininar\,Discipline]= 

10, 8, 13,2, 3/2, 5,4,4, 19, 2, 1, 11, 15, 16, 8, 7.7, 12,7, 9, 5, 4 H 
Initial Tasks(Contract,Discipline]= 

13, 8, 13, 2, 4, 2, 5, 4, 4, 20, 2. 2, 11, 18, 16, 9, 8, 8, 14, 7, 10, 5, 6 H 
Initial Tasks[Lead Ship.Discipline]= 

41, 25, 39, 6, 14, 9, 15, 12, 12, 60. 6, 6, 33, 54. 54, 35, 24, 24, 42, 21. 30. 15, \ 

18 H 

Initial Tasks[Manufacturing,Discipline]= 

14, 9, 13, 2, 5, 3, 5, 4, 4, 20, 2, 2, 11, 18, 20, 12, 8, 8. 14, 7, 10. 5, 6 
~ Tasks 

-- The baseline number of total deliverable tasks for each of the 23 design \ 
disciplines for each of the five design phases...values determined from \ 
DDG-51 Design Histories and evaluations from the La\'erglietta Design Thesis 


Review Period[Phase]= 

0.325,0.325.0.325,0.1,0.1 
-- Month 

-- Minimum time reqiured to review a single task 

I 

Design Spiral Malrix[Al,Discipline]= 

0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 . 0 . 0 , 0 . 0 , 0 . 0 , 0 , 0 . 0 , 0 , 0 , 0 , 0 . 0 ~ 

Design Spiral Matrix[A2.Discipline]= 

1.0, 1. 1. 1, 1, 1, 1, 1, 1, 1, 1. 1, 1. 1, 1, 1. 1, 1. 1, 1, 1, I'— 

Design Spiral Matrix[A3,Discipline]= 

1, 1, 0, 1, 1, 1, 0, 1, 1, 0, 0, 0, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1 ™ 

Design Spiral Matrix[Bl,Discipline]= 

1 , 1 , 0 , 0 , 0 , 1 , 1 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 . 0 , 0 . 0 . 0 

Design Spiral Matrix[B2.Disciplme]= 

1 , 1 , 0 , 1 , 0 , 1 . 0 , 0 . 0 , 0 , 0 , 0 , 0 , 0 . 0 , 0 , 0 . 0 , 0 , 0 , 0 , 0 , 0 -- 

Design Spiral Matrix[B3.Discipline]= 

1 , 1 , 0 , 0 , 1 , 0 , 0 , 0 . 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 0 . 0 , 0 , 0 , 0 , 0 , 1 -- 

Design Spiral MatrixlB4.Discipline]= 

1 , 1 , 0 , 0 , 0 , 0 , 0 , 1 , 1 , 1 , 0 , 0 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 1 , 0 ~ 

Design Spiral Matrix[B5,Discipline]= 

1 , 1 , 0 , 1 , 1 , 0 , 1 , 0 , 0 , 0 , 0 , 0 , 0 , 0 , 1 , 1 , 0 , 1 , 1 , 0 , 0 , 0 , 1 ™ 
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Design Spiral Matrix[Cl,Discipline]= 

1, 1, 0, (X 1, 1, 0, (X 0, 1. 1, 1, 1, L 1, 1, 1, h 1, 0, 0, 0, 1 H 
Design Spiral Matrix[C2,Discipline]= 

1, 1, (X 0, 1, 1, 1, 0, 0, 0, 0, 1, 1, 1, 1. 1, 1, 1. 1, 1. 1, 1, 1 H 
Design Spiral Malrix[C3,Discipline]= 

1, 1, 0, 0, 0, 0, L 0, 0, 0, 0, 1, 0, 0, 0, h 1, 0. 0, 0, 0, 0, 0 —I 
Design Spiral Matnx[C4,Discipline]= 

1, 1, 0, 0, 0. 0, 1, 0, 0, 1, 0, 0, 0, I, 0, 0, 0, 0, 0, 1, 1, 0, 0 H 

Design Spiral Matrix[C5,Discipline]= 

1, 1, 0, 1, 1. 1. 1. 0, 0, 1, 1, L 0, 1, L 1, 1, 1, 1, 0, 0, 0, 1 H 

Design Spiral Matxix[C6,Discipline]= 

1. 1. 0, 1, 1, 1, 1, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0. 0, 0, 1 H 

Design Spiral Matrix[C7,Discipline]= 

1, 1, 0, X X X X X 0. X 0, 0, 0, X 0, X X X X X X X 1 H 
Design Spiral Matrix[DXDiscipline]= 

X X 0, X X X X X 0, X 0, 0, 0, X 1, 0, X X X X 0, 0, I H 
Design Spiral Matrix[D2.Discipline]= 

X X 0, X X X X X 0, X X 0, X X X X 0. X X 0,0. 0.1H 

Design Spiral Mairix[D3,Discipline]= 

X X 0, L X X X X 0, X 0, 0, 0, X X X X 0, X X X X 1 —I 
Design Spiral Malrix[D4,Discipline]= 

X X 0, X X X X X 0, X 0. X X X. X X X X 0, X X X 1 H 
Design Spiral Matrix[D5,Discipline]= 

X X 0, X X X X X 0, X 0. 0, 0, X X X 0. 1. X 0, 0. 0. 1 H 
Design Spiral Malrix[EXDisciplinel= 

X X 0, X X X X X 0, X 0, 0, 0, X X X 0, X X 0, 0, X 1 H 

Design Spiral Matrix[E2,Discipline]= 

X X 0. X X X X X 0, X X 0,0, X X x o, x X o, x o, i h 

Design Spiral Matrix[FXDiscipline]= 

X X 0, 0, 0, 0, 0, 0, X X 0, 0, 0, X X X X X X X X X 0 
~ Tasks/Tasks 

-- The design spiral matrix (aka design structure matrix) represents the \ 
first order inpiit/output requirements associating one ship design \ 
discipline to another.,.a value of "0" indicates the discipline is not an \ 
input to tlie given element, ” 1 '* indicates a significant level of input to \ 
the element 


Min Comp Period[Phase,Discipline]= 

0.5 

~ Month 

~ Minimum period of time required to complete any given task regardless of 
the resources available is estimated to be one week (same for all tasks \ 
and all phases) 


Average Coord Period[Phase.Discipline]= 

1 

~ Month 

~ For tasks requiring coordination and personnel interaction, tliis is the \ 
average penod required to coordinate a task 


Feedback Fraction [Phase]= 
0.5 

~ Tasks/Tasks 
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